Talk:Command-line interface

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)

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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

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) [reply ]

"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)

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

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

The section on command-line interpreter seems to be more about shell (computing) than either command-line interpreter or command-line interface. Stevebroshar (talk) 15:40, 25 April 2025 (UTC) [reply ]

"command-line shell" appears to refer to an application that provides a command-line interface to the OS, whether it's shipped as part of the OS or not, as opposed to one that's wired into the OS and can't be replaced. Some systems may have had the latter - I think OpenVMS has alway had a command-line interpreter that was not only wired in but that ran in a more privileged mode than the commands it ran - but TENEX and Multics appear to have had shells of that sort.

A shell can, but is not required to, support scripting.

But the main issue is that a command-line interpreter can be part of an application, supporting only application-defined commands; it need nto be a system CLI supporting system and possibly add-on commands. Guy Harris (talk) 13:02, 22 May 2025 (UTC) [reply ]

See also the earlier discussion at § Command-line interpreter is not the same as shell. Guy Harris (talk) 19:53, 22 May 2025 (UTC) [reply ]

I don't know about TENEX, TOPS-20 or OpenVMS, but the shell in MULTICS was an unprivileged application that supported the same active functions on the CLI and in scripts.

The first CLI I'm aware of, ATS, was for an application rather than an OS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:58, 9 July 2025 (UTC) [reply ]

ATS should be mentioned in Command-line interface § Early history, to emphasize that "CLI" doesn't necessarily mean "CLS" (command-line shell, as in a command-line interface to the OS).

(The article also needs restructuring, to try to cleanly put stuff that's about command-line shells by itself, separate from stuff about the generic concept of a CLI. Or should there be a separate article about CLSes?) Guy Harris (talk) 16:09, 9 July 2025 (UTC) [reply ]

Surprise! SQLite calls its command-line interface a "command-line shell", so, apparently, "command-line shell" meaning "command-line interface to operating-system commands" isn't a universal convention. Guy Harris (talk) 20:50, 9 July 2025 (UTC) [reply ]

And the Apereo Central Authentication Service (CAS) also has a "command-line shell". Perhaps a command-line interface is a "shell" if it's a front end to a system with other lower-level interfaces, with the commands using those interfaces to manipulate the system; SQLite is a database, and I'm guessing that CAS is also a system with innards that can be manipulated by means ther than its shell. Guy Harris (talk) 21:33, 9 July 2025 (UTC) [reply ]

I would say that a shell is both a CLI and one or more scripting languages. With display terminals replacing hardcopy terminals, some CLI features are little used while new features oriented to displays are omnipresent. In the case of *ix the shell typically includes only one scripting language but supports the shebang or equivalent, e.g., EXTPROC. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:53, 9 July 2025 (UTC) [reply ]

I would say that a shell is both a CLI and one or more scripting languages. So is a text editor, or debugger, or... with a scriptable command language a shell?

With display terminals replacing hardcopy terminals, some CLI features are little used What features are those? The "new features" are presumably things such as fancy line editing, interactive history searching, etc. (although command-name and file-name completion were, I think, available on hardcopy terminals in TENEX, as they just involved having the shell typing letters for you).

In the case of *ix the shell typically includes only one scripting language but supports the shebang or equivalent UN*X shells have 1) a scriptable command language and 2) the ability to run "programs", meaning "everything you can run with an exec call", as commands. The exec calls handle #!, as well as handling machine executables (and perhaps either executables for other instruction sets, by running a binary-translator program, or for other operating systems, by running a program such as Wine).

So the shell doesn't handle #! itself, it just runs #! scripts the same way it runs executable images, without even having to determine whether frobozz is an executable image or an interpreted script.

I think cmd.exe is similar, although its scripting language isn't as nice as even the original Bourne shell and CreateProcess() doesn't have any notion of #!, so it has to handle .bat files differently from .exe files. Guy Harris (talk) 20:18, 1 August 2025 (UTC) [reply ]

I would say that contemporary debuggers and text editors include GUI shells.

Back when keyboard/printer terminals were common, many shells offered the ability to specify logical backspace and logical erase characters, as well as fancy line editing; there is little need for them on a reasonable display terminal or command window. They may still be there, but who uses them? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:05, 1 August 2025 (UTC) [reply ]

I would say that contemporary debuggers and text editors include GUI shells.

• For debuggers, the main free-software debuggers for Un*x (dbx, gdb, lldb) have CLIs, and gdb, at least, is at least somewhat scriptable. There exist GUI wrappers for gdb, and lldb is, I think, written as a library for debugging functions and a command-line interpreter using that library - I think Apple's Xcode GUI debugger is built atop that library (it may, prior to lldb, have been a GUI wrapper for gdb).
• For editors, there are command-line editors (ed, edlin, ex), "full-screen" editors (vi, various flavors of EMACS, DEC TPU/EVE), and GUI editors (I could probably fill up a significant part of the window with a list of the ones that have Wikipedia entries). Some of those are scriptable (EMACS, TPU and the editors built from it, probably some GUI editors). The vim reimplementation/extension of vi is scriptable, and David Hitz implemented a Turing machine simulator for the original vi (although he says it depends on some vi unintentional features).

Back when keyboard/printer terminals were common, many shells offered the ability to specify logical backspace and logical erase characters At least in Multics, # as the erase character and @ as the line-kill character were implemented the terminal driver ("tty DIM", for "device interface module", as I remember), so that wasn't done by the shell, it was done for anything that was reading from the terminal. DEC's OSes were similar, with RUBOUT and ^U and some other control characters handled in the driver; TENEX may have done the same. UN*Xes do that in the terminal driver as well.

as well as fancy line editing At least for UN*X shells, the fancier line editing is done by disabling terminal-driver line editing and echoing, and receiving individual characters and doing its own editing and echoing. The GNU project has a readline library to support fancy line editing; I'm not sure whether bash uses it, but I think gdb and some other GNU utilities, as well as other programs, use it.

there is little need for them on a reasonable display terminal or command window Define "reasonable". Some terminal windows, such as the ones in Apollo Domain/OS, did, I think, implement their own fancy line editing, but that's uncommon in UN*Xes (I think at least some UN*X pseudoterminals can run in a mode where the program on the controller end can hand finalized lines to the terminal end and can do its own fancy line-editing, but few, if any, terminal emulators for UN*X use that), and I use bash/ksh fancy line editing a lot. Things may be different for ISPF users, CANDE users, etc.. Guy Harris (talk) 22:50, 1 August 2025 (UTC) [reply ]

In z/OS the old line-oriented TSO TEST command gets little usage; most debugging uses various full-screen debuggers, some of which have Eclipse or VS Code GUI front ends. All of them include a command line.

Similarly, the old line-oriented TSO and CMS EDIT commands have been supplanted by the ISPF and XEDIT applications. I don't know how much traction editors like gvim and Kate have gained in the *ix world.

In OS/360 and successors, the access method did no line editing. TSO line editing was handled by the Terminal I/O Control (TIOC) for TCAM and later by Virtual Terminal I/O Control (VTIOC) for VTAM; applications like CRBE, CRJE and Wylbur handled their own line editing.

I would say that a reasonable display terminal is one that has keys or pointing devices for cursor movement, delete and insert. An example of fancy line editing that seems unnecessary now is a command that displays a line and solicits an edit request with column-oriented delete/insert requests, writes the modified line and again solicits and edit line. A common convention was to indicate an insert with a ^ under the insertion point. That sort of line editing would be pointless in, e.g., ISPF, XEDIT. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:14, 4 August 2025 (UTC) [reply ]

I don't know what the usage statistics of command-line vs. full-screen vs. GUI are on UN*Xes for editors used by programmer and for debuggers. I tend to work with a hacked-up version of microEMACS (full-screen) and with "I hate lldb's command line and I haven't looked into whether there's a way to bless gdb to allow it to debug code" non-debugger-based debugging.

I would say that a reasonable display terminal is one that has keys or pointing devices for cursor movement, delete and insert. At least for bash and ksh, the pointing devices are useful but not necessary - EMACS-style command-line editing commands are also supported, so I use ^F to go forward and ^B to go abackward; ksh, at least, supports vi-style editing commands (based on whether you set the EDITOR environment variable to select something that looks like a flavor of EMACS or like a flavor of vi). What matters is the ability to position the cursor with escape sequences and overwrite the line on the display or, if the shell in question supports insert/delete escape sequences, use them.

In OS/360 and successors, the access method did no line editing. TSO line editing was handled by the Terminal I/O Control (TIOC) ... applications like ... handled their own line editing. On UN*Xes, the line discipline or STREAMS module provides some level of line editing (most if not all UN*Xes these days provide something at a similar level to what various DEC operating systems and TENEX provide), which is what a program gets by default. They can go into "cbreak mode"/"not-canonical mode", which lets them get individual octets from the terminal or terminal emulator, and "no-echo mode", in which case they can update the line as they choose in response to various inputs and provide their own fancier line editing. (I think they all require a sufficiently capable display terminal for that - a VT100 is more than sufficient, and, these days, 99 44/100% of "terminals" are probably the VT102-ish xterm or xterm-alikes.)

An example of fancy line editing that seems unnecessary now is... I'm not sure I've ever seen anything such as that on a UN*X.

I don't know offhand how that works on Windows. I think you can ssh into a Windows box and get a command line, but I don't know whether you get the same line-editing capailities that you get with a shell on Windows Console or Windows Terminal. I also think you can have a headless Windows Server machine with a serial console, but I don't know how that works, either. For example, does cmd.exe or PowerShell handle the arrow keys and inserting/deleting characters in the middle of a line, UN*X-style, or is that done eleswhere, e.g. in the program implementing the console window? Guy Harris (talk) 06:16, 19 August 2025 (UTC) [reply ]

At least for bash and ksh, the pointing devices are useful but not necessary however, keys or pointing devices for cursor movement, delete and insert. are still necessary. Typically a PC keyboard has cursor, insert and delete keys, as does the 3270; editors designed for curses or ASCII terminals may also re-purpose control characters. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 19 August 2025 (UTC) [reply ]

however, keys or pointing devices for cursor movement, delete and insert. are still necessary. Yes, with plural "keys" possibly being used for a single operation. For example, I use a combination of the Control key and the "F" key to move the cursor one position forward and a combination of the Control key and the "B" key to move the cursor one position backward (just as, while constructing this comment, I used a combination of the Control key and the "B" key to move the cursor backward - the multi-line text widget that Safari uses for an editing window in a form supports several EMACS keystrokes). For deleting, I use the Delete key and, for inserting, I just type what I want to insert. None of those keys are anything other than those found on, for example, a Teletype Model 37 (which, if I had one, I could plug into my MacBook Pro with the aid of a USB serial adapter, set up getty to support that serial port, log in, use stty appropriately for a printing terminal, hope that the lack of support for delays in Darwin's line discipline won't jam up the terminal, and start hacking).

editors designed for curses or ASCII terminals may also re-purpose control characters Exactly - so you don't need any fancier keyboard than what you get on, for example, a Model 37 (chosen because it supports full ASCII); all you need for the sort of command-line editing that various UN*X shells provide is a display terminal that has cursor-positioning escape sequences. I.e., the bar for what's a "reasonable" display terminal is pretty low for UN*X shells' command-line editing; an ADM-3A might suffice (if the shell uses termcap/terminfo). Guy Harris (talk) 20:48, 19 August 2025 (UTC) [reply ]

Any discussion of dedicated keys versus ASCII control sequences versus combinations with other modifier keys probably belongs in a footnote rather than inline, as does any discussion of the related standard routines. In addition to cursor positioning you need shifting of the text for insert and delete, with support for both insert and over-typing. And, yes, it is a low bar. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:55, 20 August 2025 (UTC) [reply ]

It's lower than that - shifting text in the terminal isn't necessary. At 9600 "baud", you can just redisplay everything on the line after the insert/delete point, just as full-screen text editors on terminals lacking insert/delete do.

And, getting back to the original point of this subthread, with display terminals it's not that combined script interpreters/shells don't need line editing, they just provide it only for display terminals and do it similarly to full-screen text editors. At least in UN*Xand, I don't know of any shells that provided fancy line editing for hardcopy terminals - the only line editing for hardcopy terminals was what the line discipline/STREAMS module provided - the shells that provided it (ksh and bash, for example - just provided it for display terminals. Guy Harris (talk) 20:36, 20 August 2025 (UTC) [reply ]

I assume that you meant 9600 bps, and reloading the screen for every character deleted or inserted makes it incredibly jerky. BTDT,GTS.

I believe that some *ix systems supported block mode terminals back when there was still a market for them. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:25, 20 August 2025 (UTC) [reply ]

I assume that you meant 9600 bps Yes, that's why I put scare quotes around "baud"; I wasn't sure what the term that's usually used is. bps suffices.

and reloading the screen for every character deleted or inserted makes it incredibly jerky Not on a single line, as I remember.

BTDT,GTS Me, too, but what I got when I went from Computer Consoles to Sun was a poster, not a shirt. I took somebody's full-screen editor and redid a lot of it, and also wrote the original OfficePower word processor, neither of which were too bad with at 9600 baud with a VT100 - neither of them redrew the full screen (the full-screen editor just redrew the line, and the WP rewrapped the paragraph, which would only redraw stuff below the paragraph if the paragraph size in lines changed).

I believe that some *ix systems supported block mode terminals back when there was still a market for them. "Block mode" in the sense of a character-mode terminal that also supports putting up a form and having the user fill it in and hit a "transmit field contents" key (I think some DEC terminals did that, and there may have been ANSI X3.64 etc. escape sequences for that), or "block mode" as in 100% block mode like a 3270? The former were probably supported by applications running in non-cooked mode, with command-line stuff using the terminal in character mode; the latter were probably supported by data entry applications but not for command-line logins. Guy Harris (talk) 21:43, 20 August 2025 (UTC) [reply ]

The terms measure different things; depending on the modulation technique, the bps value might be twice the baud value or more.

Sometimes an insert or delete in the last line only requires re transmitting that line, but a delete or insert in a previous line requires more.

The S in BTDT,GTS is scars; I never got a shirt.

Block mode in the sense that the terminal is buffered. It updates the screen locally as the user types and transmits nothing until the user presses a transmit key (might be labelled, e.g., Enter, or just have an icon.) Contrast this with a terminal that transmits every keystroke immediately and responds to, e.g., ANSI escape sequences. I'm pretty sure that AIX supported the former. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:20, 21 August 2025 (UTC) [reply ]

The terms measure different things; depending on the modulation technique, the bps value might be twice the baud value or more. Yes, I know - again, that's why I put "baud" in scare quotes; as I remember, people spoke of "9600 baud" or "19200 baud" for high-speed lines. even though the baud rate is a symbol rate rather than a bit rate, and a V.29 modem is a 2400 baud modem, with each symbol representing 4 bits when running at 9600 bits/s.

Sometimes an insert or delete in the last line only requires re transmitting that line, but a delete or insert in a previous line requires more. Yes, it may require retransmitting the rest of the screen *if* the change to the current line affects subsequent lines. For command-line editing, there's usually only one line being edited.

Block mode in the sense that the terminal is buffered. Yes, the VT131, for example, had "Edit mode" which appears to be block mode.

I'm pretty sure that AIX supported the former. This USENET post speaks of some unspecified flavor of AIX supporting 3270 logins; I'm guessing that might have been AIX/370. Guy Harris (talk) 23:06, 21 August 2025 (UTC) [reply ]

"When the only tool you have is a screwdriver, everything looks like a nail." Then, as in the USENET article, someone gives them a screwdriver and they complain about how hard it is to pound in a nail with it.

AIX/370 and AIX/ESA supported 3270; I don't know whether any of the RISC versions supported 5250. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 22 August 2025 (UTC) [reply ]

Then, as in the USENET article, someone gives them a screwdriver and they complain about how hard it is to pound in a nail with it. That was then, this is now. The AT&T port's use case is probably now dead; any software development being done on a (削除) time-sharing machine (削除ここまで)(追記) build server (追記ここまで) is probably done by logging in over ssh or something else that doesn't involve any physical terminals. If there are any applications that are done with 3270 protocols (tn3270 or SNA if that's still used) and 3270 emulators on the user's PC rather than with Web browsers and Web forms on the user's PC, there are probably libraries for UN*Xes that handle tn3270.

I don't know whether any of the RISC versions supported 5250 For normal logins, or for 5250 applications? I suspect not the former, as, until the RISC AS/400s, S/38 and AS/400 was a different world from RS/6000, and, even with the RISC AS/400s, the hardware was similar for (削除) AS/400s (削除ここまで)(追記) IBM eServer iSeries (追記ここまで) and (削除) RS/6000 (削除ここまで)(追記) IBM eServer pSeries (追記ここまで) but they weren't the same machines - that didn't happen until the IBM Power Systems, and I don't think there would be much need for using a (削除) 5250 (削除ここまで)(追記) 5250 emulator program (追記ここまで) to log into an AIX LPAR. However, there may be libraries to support 3270 or 5250 applications running under AIX. Guy Harris (talk) 19:09, 22 August 2025 (UTC) [reply ]

There are quite a few TN3270 clients for *bsd, Linux, Mac and windoze; I don't know whether that is also the case for TN3270 servers. There is still a lot of work being done over TN3270, although these days z/OS supports, e.g. JSON, REST, SOAP. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:45, 22 August 2025 (UTC) [reply ]

CLI and GUI are not the only types of interface, and it is not at all clear that CLI was ever the most common except in the narrow context of operating systems. In the last half century there has been an immense amount of software that had entry fields in a formatted text screens on devices such as the IBM 2260, IBM 3270 and Uniscope. Any claim with regards to prevalence should be backed up with an RS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:31, 1 August 2025 (UTC) [reply ]

There were "punched card/printer" and "punched tape/printer" user interfaces (I say that rather than "batch" because I think it existed before there were batch monitors that could read in a stack of jobs from a card reader and execute them in sequence), and form-based user interfaces (not limited to block-mode terminals).

And if you're spending most of your time on the computer typing into a Web form, is that the GUI under which the browser is running, or is it "3270 for the '90's", as I think somebody may have called web forms?

I'd say that "the narrow context of operating systems" corresponds to users using a "computer" rather than using a particular application. For example, somebody working on a scientific paper might use a language processor to develop a program to do modeling, analyze data, etc. (or use an existing program for that), use text editor/text formatters/word processors to write up the paper, and email to communicate with colleagues and scientific journals; most of them probably used a CLI, at least in the pre-GUI era. Somebody at a travel agency might be communicating with one particular backend program from their terminal, without using a CLI, although, nowadays, they might be using a GUI with the Web browser being used to communicate with backend programs to make reservations and using a mail program to communicate with clients etc.. Guy Harris (talk) 20:00, 1 August 2025 (UTC) [reply ]

Yes, in the half decade from the IBM 701 and UNIVAC I until the first monitors it was all manual loading of cards and tapes for individual jobs; even after it took a while for monitors to gain traction.

By the 1970s there were a lot of applications using, e.g., IBM 2260, IBM 3270, for applications like reservations. SPF and its competitors were edging out cards and hardcopy terminals for editing. PROFS was huge. This was all formatted text screens with multiple entry fields. A clerk using PARS to book a flight wouldn't recognize a command line if it hit him in the nose. — Preceding unsigned comment added by Chatul (talk • contribs) 21:21, 1 August 2025 (UTC) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

That predates Git; the Control Program Facility ^[1] 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) [reply ]

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) [reply ]

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, (削除) XPF (削除ここまで)(削除) OS/400 (削除ここまで)IBM i .) Guy Harris (talk) 19:25, 29 September 2025 (UTC) [reply ]

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) [reply ]

(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) [reply ]

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) [reply ]

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) [reply ]

@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) [reply ]

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) [reply ]

• C-Class level-5 vital articles
• Wikipedia level-5 vital articles in Technology
• C-Class vital articles in Technology
• C-Class Computing articles
• Top-importance Computing articles
• All Computing articles

• All Wikipedia vital articles