The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not all, Windows GUI conventions and keyboard shortcuts come from CUA, and this is its lasting legacy.

That CUA was originally defined for text-mode applications as well, and indeed was based on loose conventions that had emerged within IBM for text-mode applications, has been largely forgotten. But even in the '80s there was an appreciable divide between the IBM paradigm, which was more oriented towards menus and actions (what we think of as GUI today), and the AT&T/UNIX paradigm, which was more oriented towards composition of commands.

Of course there are things like newt which have crossed the lines, but generally speaking UNIX derivatives such as Linux have tended to "stay in their lane" of command-oriented environments with minimal user assists. This could be seen as a long-lasting influence of the different I/O paradigms these platforms tended to feature in the influential '80s: UNIX systems were built around line input and output (e.g. TTYs) while IBM systems of the same era were more often built around video terminals (e.g. CRTs). This was basically because UNIX was predominantly running on hardware of opportunity (e.g. whatever the institution already had), and thus had to be flexible and not assume much, while IBM systems were more often used with terminals leased from IBM along with the machine and thus could assume the latest era of video terminal capabilities.

And then, of course, sometime around the '90s all of these platforms more or less ossified in their differences from each other, as each respective camp came to view their UI paradigm as a core feature of the platform which should not be modified.

This is just one of the ways in which UNIX and its family are much more "line-oriented" than even many of their contemporary competitors. This was partially by necessity but also partially by design as the line-oriented paradigm was easy to understand and work with, conceptually if not in practice. Ironically line-oriented input and output is often justified as being reminiscent of punched cards, when the software lineage with a far longer background in punched paper media (IBM, CDC, etc) were far quicker to get away from this model of human-computer interface than UNIX.

Put more generally, "GUI" vs "TUI" is to some degree a false dichotomy. Many of the real capabilities and interactions we associate with GUIs are also quite possible in TUIs (although the GUI version is clearly a refinement), and indeed were often implemented prior to the common availability of raster displays. When people talk about "GUI" vs "TUI" they are almost always actually talking about differing fundamental UI paradigms, which I might call action-oriented and line-oriented. Each can be implemented in a raster-mode or text-mode environment, although both generally work better in a raster-mode display (we might consider Jupyter to be an example of a line-oriented paradigm on a raster display).

You touch upon the problem. The space is actually bidimensional instead of unidimensional.

On one axis we have graphical (raster mode) at one end and text at the other. On the other we have as you calld them action-oriented (WIMP) and line-oriented (I would call it command-oriented).

There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like *Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.

And there are graphical command-oriented apps like Jupyter or ReGIS or Sixel or iTerm or TermKit or Kui or the command palette in VSCode or Atom or others.

And you can have them mixed like in youtube-dl GUI or ffmpeg GUI where the changes you make in the GUI are reflected in different arguments for the command and you can see and edit the command before executing it. This is similar to getting keyboard shortcut suggestions in menus or tooltips.

We need more innovation in this space. Ways to achieve both discoverability and scriptability. We need more hybrids and less systems that stay in their lane. Graphical text editors with command pallettes, PowerShell with its object oriented piping, Jupyter are moves in this direction.

This is a power user direction. And it is opposed both to the minimalist touch friendly trend and to the terminal-first mindset.

> There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.*

These are graphical programs, just with a substandard drawing api.

You did not get the point the parent (me) and grandparents made.

They are not graphical programs. They are generally recognised as TUI programs. If these are graphical then so is Vi or the fancy powerline prompt.

Our point was that you can also have command lines in graphical applications and WIMP in text mode applications.

https://en.wikipedia.org/wiki/Text-based_user_interface

https://en.wikipedia.org/wiki/WIMP_(computing)

Actually even this two axis classification is imprecise. CLI programs like the coreutils are actually sort of missing a user interface. They are just programs that receive arguments on launch.

How should we classify the following?

- Programs like coreutils that receive arguments and return a result

- Programs that start a menu or wizard in text mode

- Programs that start a interactive command line like various database CLI interfaces, shells

- Programs like Vim that have a TUI and are command line driven.

- Programs like Tilda that have a WIMP TUI

I think the last four have graphical equivalents (eg. Windows installers, Jupyter, VSCode, Notepad++ respectively) and what is missing is a graphical interface for passing arguments to programs.

Of course vi is graphical. Vi is literally short for 'visual': it was created as a graphical extension of ex.

The mark of a command line is a stream of commands and responses, not whether it does ascii art to emulate graphics.

I understand your point and your definition of GUI is much more inclusive. I however disagree with your definition and I consider it is not that commonly accepted.

I do agree with your definition of a command line interface as a stream of commands and responses.

> Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications?

On IBM i (originally known as OS/400), you can press a function key and automatically get a fill-in-form for any command.

This is because command line syntax is defined, not in your program's code (getopt calls etc), but using declarations in what you might consider to be a separate command definition file (technically called a "*CMD object"). The OS does command line parsing and validation, marshals the result into a memory block, and passes that to your program rather than the raw command line. And the OS uses the same command syntax declarations to generate the (text mode) fill-in form for display.

Other systems which use the idea of command line syntax declarations, with the shell doing option parsing based on those declarations instead of each program doing them itself, include OpenVMS DCL and PowerShell. (PowerShell actually copied this idea from OpenVMS DCL and IBM OS/400.)

I think the big reason why this is less common in Unix-like systems, is the design decision to give each command responsibility for parsing arguments/options, rather than doing it in the shell. This makes the whole approach of automatically generating fill-in forms at the worst impossible, at the best unreliable. You can try parsing --help output or man pages, but that method isn't always going to work, centralising option parsing in the shell does. It is likely rather too late for Unix-like systems to change their approach.

Macintosh Programmers Workshop and I believe AU/X had this sort of functionality (different implementation, though) back in the 80s/early 90s. It was nice. :)

I don't think there is a club to be in, but if you want to feel in the club about such things, just say something like "I expect that there is an option for like '-w whatever_madeupoption' that is useful here, but I'd have to take a look at the man page or use '--help' to know for sure". Be prepared to respond to "how would that work?" with APIs/syscalls/etc that you might use to implement that or say something like "I'm not sure, it sounds like an interesting problem if I had time to solve it"

There are shells that help with discovery. And auto completion helpers. These are great. You might infer from documentation. There was a big thing about spacial awareness years back, my brain works well like that, familiar brain paths for controls in certain places. But that relies on repetition. I pretty much always forget shell incantations. So any helper tools are a boon for me. Self described to GUI or richer UI would be welcome. If it's not already done.

File explorer multi pick is the thing I desperately claw for for a pointer.

More to your point. I think TUI/CLI apps would be much more usable if help files where written for Beginner, Intermediate and Advanced (or similar). With the flat format we have now man pages and --help are overwhelming when something is brand new to you.

`tldr` has been very useful for me since I discovered it.

I just keep cheatsheets handy. For new scenarios, if I find they aren't already on the sheet, I add them. The best command line tools have good documentation you can find with a command like "help" or the "-h" flag. I am slightly annoyed there isn't a convention for this though. Perhaps it should be made into a RFC standard.

Cheat sheets are not form of discoverability. People generally want to use software and learn-while-using. By searching beforehand for a cheatsheet or reading a man page you are already studying how to use the software before actually using the software.

Compare that to most GUI apps where you can just open and use and learn as you go.

I just want to achieve an outcome. An argument could also be made that GUIs are a pita because you have to spend too much time discovering when you could just read the manual and do the task.