Talk:Command-line interface

Advantages section

I do not agree with the part about the advantages of CLI's. Consistence is not an advantage of CLI's over GUI. It is an advantage over carefully designed (as said here) CLI's over uncarefully designed GUI's. In my opinion the biggest advantage of a CLI's is that it can become a second language. If I want a calendar in my CLI, I just type calendar instead of moving my mouse to the start button, clicking, looking where the item programs is, moving my mouse there, then find and move to accesoires then find and move to calendar (assuming you have a calendar there).—Preceding unsigned comment added by 130.89.198.144 (talk • contribs) 16:36, 29 May 2003

(By the way, please sign your edits to talk pages.) If you disagree with parts of the article, rewrite them. If you think it's incomplete, feel free to add a section on the disadvantages. --grendel|khan 16:13, 2004 Jun 4 (UTC)

Multitasking

Omegatron, I'm sorry but I have to disagree with your addition on September 2:

* Command line interfaces are not efficient for multitasking; they do not offer the same ability to view multiple program outputs or content simultaneously.

I commonly have literally hundreds of tasks going simultaneously in a CLI and view the output of any or several of them at once. While you may not be comfortable doing it, that does not mean it cannot be done. If it were not for the word "same" I'd have to say this sentence is completely false in my experience. No, it is not the "same" in that the output is not surrounded with GUI chrome and icons, but functionally I think you can do all the same tasks (except those that are inherently graphic, such as drawing an image): view parts of several documents at once, choose text from one document and insert it in another. Can you help me understand what you were driving at here? --Chauncey27 16:57, 28 October 2005 (UTC)

1. This is an article about CLIs. It's not CLIs vs GUIs deathmatch.
2. If you're going to compare these two very broad paradigms, you'll have to compare all different implementations at once. You can't talk about the best CLI vs the worst GUI. Compare apples with apples.
3. The current version is heavily biased in favor of (Unix-based) CLIs due to the type of people who contribute to the Wikipedia; a case of systemic bias which needs to be removed and balanced out by NPOV comparisons.
4. CLIs aren't efficient at multi-tasking, in general. Just because you can do something doesn't mean you're doing it efficiently. — Omegatron 18:28, 28 October 2005 (UTC)

Re: #3: Well most users of CLI are on a Unix-based system. The only major system that is not Unix-based is Windows, very few people use DOS for more than trivial tasks and DOS cannot do much in 2007, it cannot access much of the running system for example. But many people on Windows are using PuTTY, Cygwin and Exceed and will be using a Unix-style shell. —Preceding unsigned comment added by 82.36.234.82 (talk • contribs) 14:39 (UTC), 6 April 2007

And just be cause you can do something doesn't mean you aren't doing it efficiently. Do you have anything to suggest that multitasking in CLIs is, in general, less efficient than in GUIs? I find that (yes, unix specific) running multiple tasks through GNU Screen (either locally or through ssh) to be vastly superior to anything I have seen in any GUI. The user interfaces to programs running on the localhost are identical to those running on remote hosts. Furthermore, both interactive and non-interactive cli applications typically deal with text data. The ways in which separate programs can interact with eachother is limited only by the imagination and ability of the user. It's all just text processing.

There are areas where CLI is definately at a disadvantage to GUI. When it comes to specifically graphical applications like modeling, image manipulation, splicing video and audio together, etc. then GUI is probably the way to go in the vast majority of cases. However, multitasking under a GUI (at least any GUIs I have ever seen) is painful for anyone who has a decent amount of experience using the command line. --207.81.225.190 17:36, 3 September 2006 (UTC)

I'm not going to agree or disagree with this on multitasking, but I'll disagree with your suggestion that CLIs aren't suited to things relating to graphics. "Graphics" and "graphical user interfaces" aren't one and the same - graphics are essential for humans and GUIs are not. To use a crappy but accessible example, the website at http://uni.xkcd.com is command-line, but has graphics, but doesn't have much GUI (except for the mouseover text). To use a better example, Matlab and Mathematica. To use your own second example, image editing, a command-line is the only easy way to perform the same edit on multiple files, or to specify exact coordinates.

82.0.106.250 (talk) 16:33, 14 January 2014 (UTC)

kim@empire ~ $ ps -ef | wc -l
59
kim@empire ~ $ ssh they
Last login: Tue Feb  5 17:14:19 2008 from empire.lan
kim@they ~ $ ps -ef | wc -l
100
kim@they ~ $ ssh thex
Last login: Tue Feb  5 17:13:53 2008 from empire.lan
kim@thex ~ $ ps -ef | wc -l
50
kim@thex ~ $ ssh bruning
kim@bruning's password: 
Last login: Tue Feb  5 19:25:56 2008 from empire.lan
Tue 14 Jun 2005:

New 200GB is working fine, but jury rigged. Still gotta get it mounted properly.
Alls well! Maybe I'll move the extended directories to the 200 Gb drive, and instal gentoo over the 80 Gb one.
kim@bruning:~ > ps -ef | wc -l                                          [19:59]
    110
kim@bruning:~ > bc                                                      [19:59]
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
59+100+50+110
319
kim@bruning:~ >                                                         [20:01]

319 processes on 4 different computers. You can keep your GUI, thanks ;-) --Kim Bruning (talk) 18:44, 5 February 2008 (UTC)

And here's my Mac, the GUI "computer for the rest of us", with a whole bunch of windows open:

$ ps -ef | wc -l
    1376

Of course, being a Mac, it's a BSD-derived UNIX(R) box, and a bunch of those processes are either instances of login or bash for terminal windows - about 117 instances of each, so I guess I have 117 Terminal windows. There's only one Terminal process managing all those windows, because that's how macOS works; there'd probably be even more processes on a non-macOS UN*X with that many xterm or gnome-terminal or rxvt or Console or... windows open, or on a Windows box with that many cmd.exe windows open.

And ps -ef also lists other users' processes, as well as daemons. Try ps -u kim -f instead.

Not that counting processes is relevant here; there's "multitasking" as in "the operating system can run more than one process" and there's "multitasking" as in "how easy is it for a user to do multiple things in parallel", and the latter is, I think, what's being discussed here.

Also, there's "CUI" as in "a single terminal at which you're typing" and there's "CUI" as in "typing at a terminal".

One advantage of a GUI is that, instead of having to have a bunch of terminals on your desk and move from one to the other in order to manage various tasks being done in parallel, or having a bunch of background jobs you move between foreground and background, you can have a GUI on your machine and have a bunch of terminal emulator windows and move from one to the other in order to manage various tasks being done in parallel.

In any case, the article is no longer claiming anything about multitasking that I can see. Guy Harris (talk) 00:13, 23 May 2025 (UTC)

Wait, you don't run an x11 sub-environment on your Mac? DMacks (talk) 00:22, 23 May 2025 (UTC)

The main X11-based program I've used on my Mac is x029, but that's just because I remember, a long time ago in a galaxy far far away, punching source code into cards on an IBM 029, i.e. I used it for the lulz. Other than that, why would I run Xquartz or run any X11-based application with Xquartz? (And, at least on my Ubuntu 24.04 VM on my Mac, the X11 sub-environment is provided by a program called "Xwayland". :-)) Guy Harris (talk) 21:45, 4 October 2025 (UTC)

Strange acronym

"At least one person also calls it a CLUE, for Command Line User Environment."

That sentence is a bit odd, anybody want to explain it? Why At least one person? --Edward 13:16, 4 Jun 2004 (UTC)

The Linux Documentation Project's Introduction to Linux - A Hands on Guide uses the acronym CLUE in the opening section. I'm pretty sure there have been others as well. --grendel|khan 16:13, 2004 Jun 4 (UTC)

Yes "at least one person calls it..." just looks weird - I'll change it to "It is occasionally called..." I think. --IMSoP 13:12, 20 Jun 2004 (UTC)

MSH

Command Shell monad won't be ready for inclusion in Longhorn, guys...

"I hate the command-line"

Well, obviously, I don't. However, I have removed the link by that name, becasue I don't think its encyclopedic in nature. I also don't agree with the subject of it ("subject of it" = "I hate the command line") , but that wasn't the reason I removed it. I removed it becasue I don't think it was relavant to this article, it gave no important information about CLIs. —The preceding unsigned comment was added by Nick Warren (talk • contribs) 27 October 2005.

I had to remove it again, because someone put it back. It is one sided and it just doesn't need to be linked to in a Wikipedia article. Sorry. Now please, don't put it back. :)

CLIs derived from RSX-11 and RSTS?

The article says

Examples of command-line interpreters include Nushell, DEC's DIGITAL Command Language (DCL) in OpenVMS and RSX-11, the various Unix shells (sh, ksh, csh, tcsh, zsh, Bash, etc.), CP/M's CCP, DOS' COMMAND.COM, as well as the OS/2 and the Windows CMD.EXE programs, the latter groups being based heavily on DEC's RSX-11 and RSTS CLIs.

The first question that raises is "which of those are 'the latter groups'?" I suspect it's "CP/M's CCP, DOS' COMMAND.COM, as well as the OS/2 and the Windows CMD.EXE programs", but it could also just be referring to cmd.exe.

The second question is "in what way are they based on RSX-11 and RSTS?" The use of / as a flag argument indicator probably dates back to DEC operating systems, but that dates back at least to the PDP-6 monitor (prececessor of TOPS-10).

And the third question is "are there any references for them having been based on the Concise Command Language?" It's definitely believable that it is, given the similarities between the command languages and given Gary Kildall's use of PDP-10s running TOPS-10, but that's just original research if there aren't references for it. Guy Harris (talk) 06:59, 5 September 2025 (UTC)

If we removed "the latter groups..." it would resolve all your questions. I'd support dong that. ~Kvng (talk) 13:33, 8 September 2025 (UTC)

If somebody provides answers to those questions, they should be used to edit the paragraph. If nobody provides answers to the third question, the clause in question should be removed as being unsupported. If they haven't been answered by 2025-09-12 (1 week later), I'll remove the clause; if somebody else removes the clause before that, I won't put it back. Guy Harris (talk) 20:26, 8 September 2025 (UTC)

Command Model and REPL

This article covers the CLI through about the 2000's era. However, post Git in 2004, two modernizations have taken place. The first is Git's popularization of the object command model. cli <verb command> <noun subcommand> or in case of wp-cli cli <noun command> <verb subcommand>. The second is the popular name used by shell CLIs which is a Read Eval Print Loop or REPL. I want to start this conversation on how to conservatively evolve this article to capture modern anatony and design elements. I'll wait a week or two to capture suggestions and put something together in my sandbox to further discuss. FactStacker (talk) 12:38, 29 September 2025 (UTC)

That predates Git; the Control Program Facility on the IBM System/38 and successors is an example. Also, other paradigms are very much still in use. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:13, 29 September 2025 (UTC)

It even predates Git on UN*Xes; some other commands that can perform multiple functions have used that syntax.

(The git command itself is sort of a "shell intermediary", in that the verb gets prefixed with git-, and the result treated as an executable name, and git tries to find that program in the command search path and, if found, runs it with the arguments.)

Perhaps Git popularized it on UN*Xes. As I remember, many of the commands where I've seen that syntax are administrative commands that perform many operations on the subsystem that they administer, so most users may not have been familiar with them.

Just about every aspect of the syntax of UN*X commands is by convention; the command gets a list of tokens, which it can parse in any fashion it chooses. <command> <subfunction> <subfunction arguments> is one way to parse them. Guy Harris (talk) 18:50, 29 September 2025 (UTC)

Yes, a shell behaves like a read-eval-print loop, although the language is usually not quite as powerful as LISP.

PowerShell is a bit more like a traditional REPL; it's a language built atop .NET, not just something that runs programs.

The S/38 Control Program Facility (CPF) Control Language, as alluded to earlier by Chatul, is also a programming language that, at least when used in scripts, is compiled into machine code (well, into Technology Independent Machine Interface (TIMI or MI) code, which is later translated into real machine code), and can call system functions (see "Control Language Programs" on page 71 of the manual he mentioned). However, I don't know whether that's the case for commands entered by the user in response to a prompt, so I don't know whether it's a full-blown REPL. (This continues in CPF's successor, XPFOS/400IBM i.) Guy Harris (talk) 19:25, 29 September 2025 (UTC)

There is command prompting from a user at an IBM 5250, so it sure looks like REL. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:24, 29 September 2025 (UTC)

(REL is arguably more accurate than REPL for most command languages, as what's printed for a command is what the command itself prints, not just the result of an expression typed at the prompt.)

Yes, as I noted, but the question is whether from the prompt it's just a command language or a language such as PowerShell or CL when used for a CL program. Can you do everything from the prompt that you can do in a CL program? Guy Harris (talk) 20:45, 29 September 2025 (UTC)

Great insight. I'm loving this conversation. Let me do some expanded research based on your insight and see if there is an opportunity to provide some clarity here. If not, we can leave it be. It will take me a week but I'll get something in the sandbox to start with. FactStacker (talk) 12:33, 1 October 2025 (UTC)

References

Hybrids

I believe that there should be some discussion of systems that do not fit neatly into categories, e.g.,

Scriptable GUI

Sytems like IBM's Workplace Shell (WPS) and Apple's OpenDoc, where the plumbing of a GUI is exposed to a CLI

CLI with multiple command prompts

In IBM's Time Sharing Option (TSO) the Terminal Monitor Program (TMP) has a READY prompt and ISPF panel 6 supports the same CLI

These are the first to come to mind, but I am sure that there are others. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:20, 1 October 2025 (UTC)

What about formatted text with entry fields?

@Chatul: I'm going to replace your {{citation needed}} for tha claim in question with a {{disputed inline}} - this sounds less like "that might well be true, but it needs a citation" than like "I'm not sure that's true - this is comparing only CUIs and GUIs, but there's a third alternative" (and {{citation needed}} provoked the addition of an entry that not only didn't mention form-filling interfaces, it didn't even mention the CLI, it only gave a history of various GUI elements).

I'm guessing "formatted text with entry fields" includes, for example, either IBM 3270 or IBM 5250 on-screen forms, as well as implementing the same sort of form-filling in the host with cursor-addressable terminals.

At least for IBM mainframes and midranges, I have the impression the form-filling interface wasn't just an interface for people using a canned application to enter transactions, it was also used as an interactive user interface for administrators, program developers, etc., so it could well, at least for those machines, have been used as much as, if not more than, a CLI. In the early days of time-sharing, especially with printable terminals, the CLI may have dominated (and canned apps may also have provided command-line interfaces), but once display terminals were common, form-filling interfaces may have become dominant.

For minicomputers, microcomputers, personal computers, and workstations, I don't think it was as common as the CLI for an interactive user interface, although, for some of them, it was used for canned applications to enter transactions. Guy Harris (talk) 02:22, 4 October 2025 (UTC)

For IBM System/360 and successors, that would be 3270; for System/38 and successors, that would be 5250. I believe that the UNIVAC Uniscope falls into that category as well.

Yes, administration and program development tools made heavy use of formatted fields on a 3270.

The Control Program Facility (CPF) of the S/38 supported command completion for Control Language (CL). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 4 October 2025 (UTC)