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 | 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.