[yawpitch]

Knowing where you are in the file browser window is still in your head, it’s just because you’ve clicked from the desktop to the folder to the sub-folder that you’re aware of the current context… sure, it might be configured to display the cwd in a status line or title bar or what have you, but so does a well configured CLI. And sure, a CLI app can just delete stuff without interaction, but so could a GUI, it’s just that one’s be kept default unsafe and the other default safe because of the expected average user… if everyone was always going to be introduced to CLI/TUI first then those default safety features would be there too. What the GUI can never do well is work with things outside the CWD, and while GUIs could be scriptable, they almost never are. I wish they were, I would love to see GUIs be as inherently capable of the social effects the post is speaking to as CLIs, with a shareable artifact of your interaction, but there seem to be incentives that keep that from happening.

Honestly I don’t see there’s any reason we don’t introduce both modes to every user. Where they want to be able to do repeatable and shareable they should have that option, and where they want to click around they should have that… but until GUI frameworks are scriptable by default, with some embedded scripting language (don’t care which) that’s ubiquitously present in every window even if the writer of the app knows nothing about it, then we should be empowering users by showing them the things CLIs are inherently better at.

My guess is the work necessary to make CLIs more ergonomic is smaller than the work needed to make GUIs more scriptable, but I could be wrong.

[zzo38computer]

> What the GUI can never do well is work with things outside the CWD

This I believe you. (My idea of operating system design does not have directory structures, though.)

> Honestly I don’t see there’s any reason we don’t introduce both modes to every user.

I think it is a good idea, although good documentation will help with both modes.

> but until GUI frameworks are scriptable by default, with some embedded scripting language (don’t care which) that’s ubiquitously present in every window even if the writer of the app knows nothing about it

My idea of operating system design involves: Although the GUI windows themself do not have a scripting language, command-line windows use a scripting language called "Command, Automation, and Query Language", and can interact with all windows in the system, even if the writer of the app knows nothing about it (although if they do know about it, that can help too). (The combination of the widget library with the security model of the operating system also has a side effect of allowing GUI interactions to be recorded as well.)

> My guess is the work necessary to make CLIs more ergonomic is smaller than the work needed to make GUIs more scriptable, but I could be wrong.

I don't know, although it is helpful to do both, since CLIs and GUIs are both useful.

[eternityforest]

In the GUI, the file manager always shows you the folder contents, often with thumbnails.

Making the CLI safe at this point would cause issues people might be less careful on systems without the safe configuration.

There's a ton of possibilities with the CLI, but the more you configure it, the more nonstandard stuff you have to learn and remember the differences when you SSH into some other machine...

I think it would be fairly easy to create a GUI framework for everything an average user would want to script, that isn't already covered by a GUI app, with some kind of package manager for CLI-to-drag-and-drop bindings, but it doesn't seem like anyone has done it, at least not in a FOSS form that got traction.