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

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)