It'd still say ed is more of a TUI than CLI, albeit kind of old-school since it doesn't redraw the screen, just continuously show output and let you enter commands. Maybe "REPL" comes closer, because it's not interactive in the typical TUI way.
It'd still say ed is more of a TUI than CLI, albeit kind of old-school since it doesn't redraw the screen, just continuously show output and let you enter commands. Maybe "REPL" comes closer, because it's not interactive in the typical TUI way.
But as to that, it's slightly different than merely being able to play back a recording of commands. It IS that, but that can be applied in a way that acts more like the examples I said like sed or patch, or expect, where the script can apply some funcion to different inputs, not just playing back a recording. I'm not denying the implimentation, how the job gets done, is technically still just a recording of commands.
They are equally obviously different from the non-interative interface where all input is provided in the command line arguments and other shell syntax (pipes, redirection).
ls is a cli app. bash is an interative app that provides the cli environment in which you use ls.
I fail to see what is gained by trying make the meaning of "cli app" unclear when it definitely has an understood meaning, just because you can technically assemble the same words to mean other things. Sure in certsin contexts where you are speaking more geneticslly and more abstractly like in some research paper you may refer to a wide range of things all as "command line interface". But so what? How does noting that help in this context? (It does not)
In the case of 1, the program’s argument syntax can be referred to as the program’s “command-line interface”. But the abbreviation “CLI” usually means the interactive interface as in 2.
The latter is analogous to the notion of how TUI programs provide their own interactive interface. When making the distinction between CLI and TUI, it’s the latter that is meant, i.e. is it a line-oriented or screen-oriented user interface.
Saying “CLI editor” doesn’t imply that the editor commands are necessarily invoked as non-interactive shell commands, as opposed to the editor providing a CLI of its own.
Technically, every program can serve as a “CLI command”, since you can invoke it with arguments. However, “command line” is generally understood to mean the user interface where the user types commands, as opposed to non-interactive program invocation. When invoking a program with arguments from another program with exec or similar, you don’t call that a CLI.
TUI apps aren't common anymore, which adds to the confusion as a lot of people didn't grow up with them and don't grasp the difference. A TUI app takes control of the terminal and redraws different parts of the screen to present a consistent, non-scrolling experience. If you've ever used a system where your interface was an IBM 3270 emulator (or better, an actual 3270 terminal), that's TUI. vi/vim and non-GUI Emacs are also TUI.
A CLI app just prints its output at the cursor and the output scrolls off the top of the screen as you go. The Bourne, Korn, Bourne Again, and C shells are all CLI, as are most REPLs and the majority of interactive non-GUI UNIX programs (including ed) these days.