Command line interface

A command line interface or CLI is a method of human-computer interaction by giving it lines of textual commands (that is, a sequence of characters) either from computer keyboard input or from a script (computer programming). They were originally developed for interfacing with computers over teletype machines in the 1950s. It is occasionally also referred to as a CLUE, for Command Line User Environment. Some argue that the CLI is not actually a user interface at all, but a programming language, entered one line at a time, and has very little utility for users compared to developers. Indeed, command lines are most often used in scientific or engineering environments for programming.

In its simplest form, the computer displays a command prompt, the user types a command on the keyboard and terminates the command with a keyboard key (usually the Enter key) and the computer executes the command. The computer then carries out the command given. The term is usually used in contrast to a graphical user interface (GUI) in which commands are typically issued by moving a pointer (via a pointing device) to a zone of the screen and pressing a button mounted on the pointing device (clicking).

Programs that implement these interfaces are often called command line interpreters. Examples of such programs include the various different Unix shells, OpenVMS DIGITAL Command Language (Digital Command Language), and related designs like CP/M and DOS s COMMAND.COM, both based heavily on Digital Equipment Corporation s RSX and RSTS operating system interfaces (which were also command line interfaces). Microsoft claims their next major operating system, Windows Vista, will include an enhanced command line interface named MSH (shell) (Microsoft Shell, codename Monad ), which combines the features of traditional Unix shells with the object-oriented Microsoft .NET.

Some applications provide command lines as well. The CAD program AutoCAD is a prominent example. Another excellent example is the engineering/scientific numerical computation package Matlab, in which practically no GUI exists and/or is unnecessary for performing most of the calculations. In some computing environments like the Oberon operating system or Smalltalk user interface, most of the text which appears on the screen may be used for giving commands.

The commands given on a command line interface are often of the form

[doSomething] [how] [toAFile]

or

[doSomething] [how] < [inputFile] > [outputFile]

doSomething corresponds to a verb, how to an adverb (it describes how the command should be performed in this instance for example, should it be particularly verbose , or particularly quiet ) and toAFile to an object (often one or more files) against which the command should be run. The standalone > in the second example is a redirection character, telling the operating system (i.e., usually a command shell interpreter) to send the output of the previous commands (that is, those on the left of > ) to some other place (that is, the file named to the right of the > ). Another common and important redirection character is the Vertical bar ( | ), which tells the CLI to treat the output of this command as the input of another; this can be a very powerful mechanism for the user, as explained under pipeline (Unix) and pipes and filters.

= Advantages of a command line interface =

Even though new users seem to learn GUIs more quickly to perform common operations, well-designed CLIs have several advantages:

Skilled users are able to use a command line faster than a GUI for many tasks. This advantage is magnified by tab completion and by the fact that programs intended to be run from the command line are often given very short names.

Options and operations are often invokable in a consistent form, one level away from the basic command. With most GUIs, the available operations and options may appear on different menus with differing usage patterns. They may be separated on several different menu levels as well. In either case, different applications (or utilities) may have different patterns; if so there is little advantage in either approach. Both are likely to annoy users.

All options and operations are controlled in more or less the same way. The more or less in this case is a common accusation against CLIs: it should be no more difficult to understand and perform a rare operation than a common one, but in practice it may require learning previously unencountered syntax. However, few GUIs offer even comparable access to their entire range of available options.

CLIs can often double as scripting programming languages and can perform operations in a batch processing mode without user interaction. That means that once an operation is analyzed and understood, a script implementing that understanding can be written and saved. The operation can thereafter be carried out with no further analysis and design effort. With GUIs, users must start over at the beginning every time, as GUI scripting (if available at all) is almost always more limited although macros can sometimes be used in a similar way. Simple commands do not even need an actual script, as the completed command can usually be assigned a name (called in some CLIs an alias ) and executed simply by typing that name into the CLI. This also means that many CLIs let users define a custom vocabulary if they don t like the one that came with the system. If a user finds it easier to remember that the print function is called print , she can make it so.

The keyboard can be a more precise input device than the mouse. Even people who are not accomplished typists could accurately enter the sequence abcde twenty times in a row without error, while it is difficult to exactly control or repeat a mouse movement even twice in a row. Moreover, typing errors can usually be corrected with a backspace or delete key before the command is submitted for processing, while the ability to correct or undo mouse errors is generally left to the idiosyncrasies of whatever program the user may be using. Finally, some command languages allow users to go back to previous commands, correct or improve them, and resubmit them. Thus users may find it easier to reliably control their computers with their keyboards.

Command-line interfaces require much less network bandwidth to run remotely; while a CLI may run acceptably over a 9600 baud serial port, a GUI consists of much more data. Similarly, modern CLIs require much less in the way of system resources, such as processor time and memory, to run than modern GUIs.

GUI advocates claim the support of Usability researchers, arguing that among other things the GUI gives the users symbols with which they can interact more intuitively, and that users should not be expected to know how things work. However, this layer of abstraction can also hinder usability. Those whose profession includes providing technical support to such users often observe that the users frustrations and lost productivity are directly caused by their unwillingness or inability to understand how their chosen tool works. Because the GUI masks what s really going on internally, it misleads the users into attempting to manipulate a symbolic representation of an object rather than the actual object. When the visual metaphor is not perfectly aligned with the reality, confusion results. A typical CLI puts the user in direct contact with whatever she is trying to manipulate. To put it in usability terms, when you have a GUI between you and the internals, you can t really see what s going on.

Some GUIs, in the name of usability , try to learn what programs are used most or which documents were opened recently, allowing the GUI to offer customized menus tailored to each situation. Unfortunately, a side effect of this is that the menus are constantly changing, forcing the user into a tightly interactive relationship with the computer which requires visually scanning for the desired icon or file name to trigger recognition memory, which can lead to mode errors. Because many CLIs are designed for scripting, they do not change over time unless deliberately changed (see modeless). This means using recall memory to complete a frequently-repeated task is more likely to work. One can quickly issue repetitively-used directives to the computer without interrupting their train of thought to constantly scan the screen and react to the computer s changing state.

Typeahead, the ability to continue issuing commands while the computer is processing some lengthy step, is much more likely to produce the intended result than the GUI equivalent, clickahead . With a GUI, the user constantly has to stop and wait for the computer to catch up.

Most CLIs maintain the concept of a working directory, which means users can go to the area where they want to work, stay there awhile, and complete several operations on the same file or group of files. Most GUIs, by contrast, have users navigating back to their workspace over and over every time they open the next file or program.

Well-designed CLIs are organized by functions, such as sort or print . Thus once the user learns how to sort one thing, the user can sort anything using the same tool. With a GUI, the user often finds a wide array of functions collected in a monolithic program, and slightly different implementations of many of the same functions in the next program, requiring the user to relearn how to sort depending on what is to be sorted. Moreover, these functions frequently change with each upgrade to the monolithic program, requiring relearning yet again. A CLI, being designed for use from scripts, generally does not change the interface to commonly-used functions from one version to the next.

Many CLIs provide an option to redirect the output of a command to a file, or to another command. To see how this is useful, consider an example: Suppose the user wants to check how much disk space is available on each of 20 computers. The appropriate command(s) could be determined, then performed on each computer. The resulting output files could be collected in one place, and used as the input to another command to produce the desired summary. In a similar fashion one could track disk space over time, by running the command each hour or day. This data capture function could even be fully automated. However in a GUI environment if the desired information can only be displayed on the screen, it becomes necessary to write down the significant number(s), or use some functions such as copy and paste to capture the data. Because the idea of capturing a program s output is not as frequently used by GUI programmers, they sometimes forget to enable the copy function in what they thought was just a simple dialog box.

No pop-ups.

A well-designed character-based addressing scheme can manage vast quantities of information, far beyond what would be practical with a GUI. For example, a desktop or window could display perhaps one or two hundred icons without scrolling. Usability experts could argue that such an interface is more intuitive, because the user could recognize a favorite icon instead of needing to remember a file s name. However with more than a few files, icons are commonly duplicated. (GUI designers often implicitly acknowledge this weakness by showing the file s name near its icon.) Others may say that the desired file is easy to find in a GUI, because it is in a familiar location on the screen. But if files are added to or deleted from a collection, icons can move around. By contrast, the World Wide Web uses a text-based addressing scheme to manage billions of documents. Imagine a GUI with an icon for each and every website. It would be overwhelming. Could anyone navigate the web without a keyboard Although one could click links from one document to the next, it is very difficult to find that first page without typing a URL or a search keyword. Similarly, a few words typed at a command-line prompt can unambiguously identify the desired file from a collection of millions, far faster and more precisely than navigating a heirarchy of icons.

Another advantage command-line interfaces can offer, when working with larger collections of most anything digital, can best be illustrated with an example. Suppose one has a directory (some call it a folder ) with 20 files in it, and one wants to print all 20 files. With a CLI this can be as simple as typing print * . Compare this amount of effort with the effort needed to double-click a file, wait for it to open, click the print icon, click something to close the document, and then tediously repeat this sequence 19 more times! Now imagine performing some more complicated function on thousands of files instead of just 20. It is much easier to type a command that means do this to all of these instead of dealing with each one individually.

In summary, while a command language admittedly takes some time to learn, those who have done so find it a far more effective way of controlling their computers. As an analogy, consider spoken language. Though it must be learned, few regret doing so, or have trouble recalling common words or how to use them. Once having learned a language, to be deprived of it is like going to a foreign country where one can only point at what one wants.

= Disadvantages of a command line interface =

Before any of the above advantages of CLIs over GUIs can be realized, a thorough knowledge of commands, command structures and options must be acquired. Learning CLI commands requires more long-term and short-term memory.

While a GUI often gives choices and simply asks the user to decide between them, or at least hints at what types of input can be entered, the CLI presents a blank prompt and assumes the user already knows every possible command, or can figure out where to find them.

Command line interfaces require Recollection for routine functions that are repeated many times a day, instead of Recollection, which some claim is the more natural way for humans to navigate and interact with their environment. For less common tasks, a CLI typically requires the user to read help pages, learn about the tools available, choose the ones suitable to the goal, and plan a sequence of steps to achieve the desired result, devising corrective action if things do not go as expected.

CLIs have a steeper learning curve than GUIs more time and effort must be devoted to learning the basics before even simple tasks may be accomplished, making them unsuitable for newcomers. Learnability of commands is poor.

While a GUI presents high-level functions such as documents and graphics that a user is interested in manipulating for accomplishing tasks, a command-line interface is a low-level interface with functions tailored more for behind the scenes interaction and programming. CLI enthusiasts claim that lower-level is better, and gives the user a better knowledge of how the computer works. Usability theory advocates that users should not know how the internals of the computer work, but spend their time accomplishing higher-level productive tasks.

Critics claim that command-line-like interfaces are only included in software due to a lack of proficiency or motivation on the part of developers to create a complete user interface. Rather than writing a comprehensive interface, the developers only write some basic functions, and then include a way to access the underlying low-level functionality as a Kludge for when the user needs to do more, leaving the extra work to them.

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

It is often more difficult to perform a rarely-used operation than a common one, and often requires learning previously unencountered syntax.

Input errors are frequent.

Command line switches differ between programs for similar functions, increasing the amount of memorization required to interact with the machine and making each program a new learning task in itself.

Some typing proficiency and familiarity with the keyboard layout is needed.

CLIs are unsuited to certain tasks, such as image editing.

There was a time when typing was considered women s work and traditional men in positions of power thought it demeaning to touch a keyboard. In the early history of desktop computers, such men wanted nothing to do with them. But when it became possible to use a computer with one hand and no typing, much of this resistance melted away.

=See also=

Text user interface

which includes a history of CLIs and GUIs.

=External links=

[http://getpot.sourceforge.net/ GetPot. Object oriented command line parsing. ] Library available for C++, Python, Java, and Ruby.

*[http://www.commandline.org.uk Command Line Warriors] an open site about Command Line Computing.

The Interaction-Design.org Encyclopedia entry on [http://www.interaction-design.org/encyclopedia/interaction_styles.html Interaction Styles, comparing Command Line Interfaces with other Interaction Styles]

*[http://www.developer.com/net/net/article.php/3286851 Coming Soon to Windows: The Microsoft Shell (MSH) by Jason Nadal]

[http://www.igeek.com/articles/OS/CommandLines.txt Command lines versus GUIs]

[http://www.courteousminer.com/wp/p=338 I hate the command-line interface.] An article criticizing CLIs