[jodrellblank]

It's awful UX for a program to know that you used it wrong, to be able to print the help there and then, and instead to tell you off and instruct you to ask politely (with --help). People who think that's okay in CLI world hate that kind of uppity-C3PO-servant behaviour from an LLM.

    $ thing
    usage: -lscekm4urytmvjpq9i8u3o54ernymctpwi8eruymgv
    ah ah ah, <finger wag>, ask nicely for: --help

    $ thing -h
    ERROR! There is no option -h
    What could you possibly want?
    It's a mystery!
    What if -h was rm -rf /  did you even think of that?
    Could have printed actual help here,
    Filling up your screen with text anyway

and then you ask for --help and get five screens starting with "-a initialize line feed motor on electromechanical teletype output device from 1964" and on and on with options nobody uses mixed with the same priority amongst parameters everyone uses.

This is yet another area where GUI programs on Windows 98[1] were better than today's Linux state of the art: pressing F1 opening a separate window with HTML-based help with contents, colours, fonts, text styles, hyperlinks, tables, pictures, an index, a search, is so vastly superior that it's unbelievable[2] that here we are in 2026 and Linux world is still infighting over whether a pager is a sign of weakness and low status, or whether showing help by default is a sign of a low quality programmer, for a problem that was completely solved during the Clinton Administration! (And presumably solved in a similar way earlier by classic MacOS, earlier by Amiga OS, and earlier at Xerox PARC).

Having a single output stream and trying to do everything on it is just bad design. Having the program guess what you want, or a toggle to change between working and being informative, or an environment variable to trigger the toggle, are downstream problems that can never please everybody, to avoid facing the bad design and dealing with it.

[1] https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help

[2] it's completely believable

[roundabout-host]

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.

[jodrellblank]

> You are comparing CLIs to GUIs.

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.