Command Line Interface

You tell the program what to do by typing at it. Contrast with: GraphicalUserInterface

A third option, not nearly as well-known, is editable text interface, employed by Wiki and many subprograms written into Emacs.

This isn't a third option; it's something that is part of GUIs and CLIs alike.

For a hybrid, see: CommandLineGuiCombo

I remember fondly my first two command line interfaces. The first was a part of Atari BASIC. It gave me a "READY" prompt, and I could enter programs into it and run them. The second was a game called Zork I by Infocom. It would describe a setting to me, and I would type what I wanted my character to do, and it would tell me what happened when my character did it. In 1983, that's what computers were like. I was six years old, and I didn't question it.

In 2001, I wonder what a six-year-old would think of it. -- NickBensema

Of interest might be NealStephenson's InTheBeginningWasTheCommandLine, in which he notes, among other much funnier and more insightful observations, that the CommandLineInterface didn't have a name until there was an alternative...

In the late 1970's it was called the prompt. even though it may have only been a blinking cursor. -- DonaldNoyes

At the beginning of the 1970's it was an innovation which replaced having a deck of punched cards which went off in a van and the output came back in the morning. -- JohnFletcher

I think for some tasks, a well-designed CLI is better than a GUI from an efficiency standpoint (but not necessarily from an intuitive or initial learning standpoint). For example, here is an example of a CLI file browser:

  prompt> SF FOO     // search folder for folder-names containing "foo"
  1. Foo Foo the dog
  2. Tran Foon, the fast runner
  3. The Windy Monfoon Season
  (Other options: X=exit, R=refine, T=repeat, H=help)
  Press digit> 3
  Opening "The Windy Monfoon Season" ...

To me, this is usually quicker than reading a long list of file names and then double-clicking. I am not a speed reader and current GUI OS's love to dump big lists in your lap. (If too many matches were found, then one could enter a longer search string or refine the search, not shown here.) I still use the DOS prompt for some operations, even though DOS is not the ideal CLI. Another advantage of a CLI is that one can tune it to their needs easier. It is easier to script-up a CLI than a GUI. There is an art to well-defined CLI's. Note that "press" prompts don't need Enter pressed. The prompt would say "Enter digit>" if Enter was required. (Early time-share systems didn't have this option, and Enter was always required, though.) -- AnonymousDonor

With an appropriate interface, such as NysLte, an operations such as described above can be accomplished with the following: a focus change click, five keystrokes (to enter *foo*) and a double click on any selected item that appears in the file list (that is 8 clicks - the example above uses 9 clicks), the file (page) can be not only displayed, but edited, and saved, or with a selection double click a change to another file (page). That's only 2 more clicks, In the CLI one would have do whatever was necessary to close the existing file (say perhaps with a control-z) then enter as many as 7 more to re-enter SF FOO (enter), and then selection of another digit. Or as few more as four if some sort of function key enter sequence would re-enter the last prompt response and selecting a digit. In either case the number of clicks for the GUI is less because of inherent programmed features, far more efficient than a script in a CLI. -- DonaldNoyes

I always have a problem with counting mouse clicks and keystrokes. For someone who can touch type, "SF FOO<enter>" can be approximately the same as one move-and-click. But, for someone who can't touch type, I can imagine that each keystroke is about the same as a move-and-click. -- DougKing

If for "can be approximately the same" you substitute "can take about the same time" and I'll agree. But even using that metric, there are many tasks for which the CLI is a a poor time-saver, compared with a gui. Example: Creating a reasonably sophisticated Web-Page. Where confusion arises in any such comparison is in just what you are doing. In the case of entering commands which execute programs, or initiate processes, the CLI may be the better alternative for some. But in cases where choices must be made in a context of many dependencies, the gui has a much better chance of providing efficient means. Both have their uses, and an intelligent-user can best decide which to use as well as when. -- DonaldNoyes

Or as few more as four if some sort of function key enter sequence would re-enter the last prompt response and selecting a digit. In most *nix shells and *DOS shells, there is a history feature that lets the user "re-enter prompt responses" by pressing the up arrow. -- AnonymousDonor

One of the differences in the CLI and the GUI as effective interfaces is in where the process intelligence resides. The CLI is most useful to one who has knowledge of what the interface provides and has a lot of navigational knowledge and experience. The GUI exerts far less requirement for prior knowledge. A three-year old child is much more likely to be found using a GUI to accomplish something useful in an interactive session, and to learn from the interaction, than they will be using a CLI which depends more heavily on reading and prior knowledge skills. -- DonaldNoyes

In the mid-80's, my company was hired to train two university secretarial pools in office automation. One group was equipped with Macintosh computers, the other with MSDOS-based PCs. Both groups appeared to be approximately equal in average intelligence and ability, and both lacked any prior computer experience, so we used this as an opportunity to do some informal, non-rigorous research into GUI vs. CLI ease of learning.

We found the CLI group became proficient, on average, somewhat more quickly than the GUI group. We attributed this to the fact that the CLI immediately fit within the secretarys' expectations of what a computer should be, i.e., something to which you must issue commands in order to perform tasks. The GUI group, however, found the abstract desktop metaphor, using a mouse and especially the relationship between physical motion in a horizontally plane affecting a pointer moving in a vertical plane, and the need to convert command ideas (e.g., "I want to use the word processor.") into GUI tasks all a bit of a hurdle that took considerable (and for some, quite stressful) familiarisation.

In the end, both groups seemed equally productive. -- DaveVoorhis

Remember the good ol' days of BSD??? I have a BSD machine running x11, but I mainly use CLI programs like vim for text editing and lynx for web browsing. I prefer twm over the default CLI because I like multiple draggable windows, but that's it. And those are my two cents.

CategoryInterface, CategoryUserInterface, CategoryCommandLine