> For a cli text editor, ed would qualify, right?

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.

▲

layer8 a day ago | parent | next [-]

I fail to see the difference between REPL and CLI here. Any line-based interactive interface where you type commands is a CLI, like for example the ftp or mysql clients in interactive mode. Or, indeed, ed.

▲

MobiusHorizons a day ago | parent | next [-]

Personally I usually make the distinction based on whether the process has to switch the tty to raw mode and overwrites the full screen (typically using ncurses), but it sounds like the person you are replying to makes the distinction in whether the program needs user input while executing. I guess such programs are more likely to work in pipelines or shell scripts

	▲	layer8 a day ago \| parent [-]
		Unix shells “need user input while executing” in that sense. A program not being a Unix shell doesn’t make it non-CLI. A shell constitutes a CLI due to its interactive line-based user interface. Any other program with such an interface counts as being a CLI program for the same reason.

▲

kristjansson a day ago | parent | prev | next [-]

Could you run it on an actual teletype without consuming an entire forest worth of paper? That’s a CLI. Otherwise it’s a TUI.

▲

layer8 a day ago | parent [-]

I don’t agree, it’s consecutive line output vs. screen-based rendering and repositioning. Regardless, ed was developed for and used on actual teletypes. It’s entire interface is geared towards that usage.

▲

Brian_K_White a day ago | parent [-]

I think ed also served the function of sed and patch. Ie you could record a bunch of edits into a file and it could read the script and perform all the edits to some input file. So it was more useful than an interactive line based editor sounds.

▲

layer8 a day ago | parent [-]

This is the same distinction as between running commands with bash -c (or just by executing a regular Bash script) and running them manually in an interactive Bash session. It’s pretty much an inherent feature of command-line interfaces that you can script them.

	▲	Brian_K_White 18 hours ago \| parent \| next [-]
		Wasn't intended to be a distinction but an aside. 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.
	▲	lern_too_spel 10 hours ago \| parent \| prev [-]
		It's different. Grep was a function of ed ('g/re/p') that was later extracted into its own program to search files that could not fit in memory. Sed then came along and implemented the 's/re/substitution/' functionality from ed for the streaming use case.

▲

Brian_K_White a day ago | parent | prev [-]

They are obviously "command line interfaces" in that the interface is that you enter lines 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)

	▲	layer8 a day ago \| parent [-]
		I disagree that it is well-understood in the way you describe. I agree that there are two distinct concepts: 1. Programs that can be run as a CLI command, often without further user interaction (but consider cases like rm -i, which are quite common), and 2. programs that expose their functionality by providing their own interactive CLI. 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.

▲

Jenk a day ago | parent | prev | next [-]

Ed was designed in an age where the visual interface was a printer - so it is most assuredly a cli tool :)

▲

a day ago | parent | prev | next [-]

[deleted]

▲

hamburglar a day ago | parent | prev | next [-]

Is it actually important that we come up with a formal definition of these things, though? They are colloquial terms, there is some overlap, and people are always going to use one or the other “incorrectly” according to you. It’s more important that we recognize that’s a potential source of differing terminology and ignore that rather than fixating on it.

▲

WD-42 a day ago | parent | prev [-]

Not sure why you are downvoted this is entirely correct

	▲	spauldo 16 hours ago \| parent [-]
		Probably because most of us don't think it's correct at all. 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.