|
|
|
|
|
|
by roundabout-host
12 days ago
|
|
|
You are comparing CLIs to GUIs. Anyways, there are GNU/Linux GUIs with the help manual (often still F1), but I would attribute the lack of manuals in some newer GUIs to a general trend against manuals, which can be seen well in Android/iOS apps, where everything has to be "engagement-optimised" and "flow-based" and with lots of blob illustrations, because otherwise people are too lazy to read even a page about how to use the app. |
|
|
Yes, and GUIs are winning again as they so often do, but also no I'm not; you can be in PowerShell CLI and run `Get-Help thing -Online` and have it launch a GUI web browser to the URI that `thing` declared as its help page. You can run `gci | out-gridview` and get a PowerShell object stream input to a GUI item picker. And on other machines you can run `ls | gvim -` and get a GUI that's reading from command line stdin.
But also no I'm not: look in this thread, part of the distinction is composability, part is interactive vs non-interactive use, part is whether the workflow gets paused, part is whether the output is desired by default or should be requested on demand, and part is whether the output stays on screen or is cleared. There can be no answer from all of these differing desires which pleases everyone, and that's a total failure of imagination.
CLIs can have jobs and background jobs and there's no official standard or de-facto standard for having the running job go into the background to display the help or paged output in the foreground. CLIs can have multiplexors, screen and tmux, and editors EMACS and VIM which have buffers and windows, and there's no official or de-facto standards for different output streams to open in either different buffers or split-windows, or in tiling window manager windows. There's options to export PAGER= but there's no standard way to indicate interactive vs non-interactive use, only trying to divine intent on a tool-by-tool basis by checking if a TTY is attached. Rustc and Elm and Odin and other language compilers have stretched to provide helpful error messages which make pretty good guesses what the user was trying to do, explain why it won't work, and suggest what to do instead, but shells and CLI tools in general have none of that.
Even without going to Alan Kay and Brett Victor extremes, Linux/Unix world has this widespread lack of imagination for what computers could be and do, and only this fruitless status bickering where computers are just another way to compete in the Suffering/Purity Olympics.