Differences between revisions 20 and 21
Revision 20 as of 2011-05-09 23:39:51
Size: 6567
Editor: ?JakubWilk
Comment: Pipe is |, not ||
Revision 21 as of 2015-10-14 09:09:13
Size: 6551
Editor: vauss
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[CommandLine|English]] - [[fr/CommandLine|Français]] - [[it/CommandLine|Italiano]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]|| ||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[fr/CommandLine|Français]] - [[it/CommandLine|Italiano]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]||

Translation(s): English - Français - Italiano

(!) ?Discussion


A command line interface or CLI is a method of interacting with a computer by giving it lines of textual commands (that is, a sequence of characters) either from keyboard input or from a script. It is occasionally also referred to as a CLUE, for Command Line User Environment. In its simplest form, the user types a command after the computer displays a prompt character. The computer system (that is, the program then accepting such input) then carries out the command given. The result may be textual output, or the initialization and running of some program, or a modification to the graphical output on a monitor or printer, or some change in a file system (for example, delete a file, modify a file, or create a file).

The term is usually used in contrast to a graphical user interface (GUI) in which commands are typically issued by moving a pointer (such as, a mouse cursor) and/or pressing a key (that is, by "clicking", often on a key mounted on a mouse).

Programs that implement these interfaces are often called command line interpreters. Examples of such programs include the various different shells, VMS DCL (Digital Command Language), and related designs like CP/M and DOS's command.com, both based heavily on DEC's RSX and RSTS operating system interfaces (which were also command line interfaces).

There are other programs which use CLI as well. The CAD program AutoCAD is a prominent example. 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 Pipe_(Unix) and Pipes_and_filters.

Advantages of a command line interface

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

  • Skilled users may be able to use a command line faster than a GUI for simple tasks, especially with the advent of tab completion. Programs intended to be run from the command line often have intentionally very short names so that they can be invoked with only a few keystrokes.
  • All options and operations are invokable in a consistent form, one "level" away from the basic command. With most GUI, the available operations and options often 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 GUI offer even comparable access to their entire range of available options.

  • CLI can often double as scripting languages (see ShellScript) 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 GUI, 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 (an alias) and executed simply by typing that name into the CLI.

  • Scripted commands (and text in files) are easily documented. The documentation can include more than the scripts' functionality. Other important elements to document include, when the script needs to be run, why the script is needed, what choices were made when deciding what the script should do and how it should do it and other such information essential to understanding what is going on and why. Comprehensive documentation is invaluable in system administration over the long term. Even short jottings can be a life saver. GUIs generally provide no means by which settings can be documented and it is consequently often a mystery why settings are as they are found to be.

  • Scripts (and other text files) are easily copied from system to system and it is easy to make simple global adjustments using standard textual search and replace. This can greatly aid the administration of multiple systems. GUIs generally provide no means of copying configurations, for backup. duplication or any other purpose, or of re-creating similar configurations on multiple machines.