Command line interface

From Wikipedia, the free encyclopedia

A command line interface or CLI is a tool for interacting with computers, often using a text terminal. Commands are entered as lines of text (that is, sequences of typed characters) from a keyboard, and output is also received as text. CLIs originated when teletype machines were connected to computers in the 1950s. In terms of immediate interaction and feedback, they represented an advance over the use of punch cards.

With the use of CRTs as interface devices, CLIs began evolving toward graphical user interfaces (GUIs) like Microsoft Windows, Mac OS, and the X Window System. These were largely supplanted by GUIs when Microsoft — in response to the success of Apple's release of the Macintosh OS in 1984 — introduced Windows the following year. Nevertheless, a significant minority of computer users prefer to use CLIs, because they feel that CLIs provide an environment with enhanced productivity. CLIs remain extremely popular for embedded systems, such as network devices.

CLIs are often used by programmers and system administrators (especially in Unix-based operating systems), in engineering and scientific environments, and by a smaller subset of technically advanced home users. CLIs are also popular among people with visual disability.

A program that implements such interface is often called a command line interpreter or shell. Examples include the various Unix shells (sh, ksh, csh, tcsh, bash, etc.), the historical CP/M, and DOS's command.com ("Command Prompt"), the latter two based heavily on DEC's RSX and RSTS CLIs.

In late 2006, Microsoft plans to release Windows PowerShell (formerly codenamed Monad), which hopes to combine features of traditional Unix shells with their object-oriented .NET Framework. Windows' current CLI programs like COMMAND.COM and Windows Script Host are commonly considered inadequate or insecure. MinGW and Cygwin are open source packages for Windows that offers a true Unix CLI. Microsoft provides a Unix CLI for Windows through their Services for UNIX add-on.

Contents 1 Anatomy of a CLI 2 Command Prompt 3 CLI vs GUI 4 References 5 See also 6 External links

[edit] Anatomy of a CLI

A CLI can generally be considered as consisting of syntax and semantics. The syntax is the grammar that all commands must follow. In the case of Operating Systems (OS), MS-DOS and UNIX each define their own set of rules that all commands must follow. In the case of embedded systems, each vendor, such as Nortel, Juniper Networks or Cisco Systems, each define their own proprietary set of rules that all commands within their CLI conform to. These rules also dictate how a user navigates through the system of commands.

The semantics define what sort of operations are possible, and on what sort of data these operations can be performed.

It may be possible for two different CLIs to agree on either syntax or semantics, but it is only when they agree on both that they can be considered sufficiently similar to allow users to use both systems without needing to relearn anything as well as enable re-use of scripts.

In its simplest form, a CLI displays a prompt, the user types a command on the keyboard and terminates the command (usually with the Enter key), and the computer executes the command, providing textual output.

Unlike a button or menu item in a GUI, a command line is typically self-documenting, stating exactly what the user wants done. In addition, command lines usually include many defaults that can be changed to customize the results. Command-line commands can be saved by assigning a character string or alias to represent the full command, or several commands can be grouped to perform a more complex sequence -- for instance, compile the program, install it, and run it -- creating a single command, called a command procedure. These advantages mean that a user has to figure out a command or series of commands only once, because they can be saved to use again.

The commands given to a CLI are often of the form

[doSomething] [how] [toFiles]

or

[doSomething] [how] [sourceFile] [destinationFile]

or

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

doSomething is in effect to a verb, how an adverb (for example, should the command be executed "verbosely" or "quietly") and toFiles an object or objects (typically one or more files) on which the command should act. The '>' in the second example is a redirection character, telling the command line interpreter to send the output of the command not to the screen but to the file named on the right of the '>'. Another redirection character is the pipe ('|'), which tells the CLI to use the output of one command as the input to the next command; this "operator-stream" mechanism can be very powerful.

Another aspect of a CLI is navigation. Navigation is how a user moves through a system. In some CLIs, the commands a user is able to issue is decoupled from their conceptual place within the command hierarchy. This usually involves being able to specify relative or absolute paths to command and data. Examples of this sort of system include MS-DOS and UNIX, which both provide forms of a change directory command to take users through a set of directories that hold command and data. Other CLIs limit the set of commands that a user can perform to the place within the command hierarchy. The place within the hierarchy and the options available are often referred to as a mode. In these systems the user might traverse through a series of sub-hierarchies, each with their own set of commands. For example, if the CLI had two modes called interfaces and system, the user would enter the word 'interface' at the command prompt and then enter an interface mode. At this point system commands are not accessible and would not be accessible until the user explicitly exits the interface model. Within the interface mode, the user would have access to a series of commands, and perhaps additional command modes.

[edit] Command Prompt

A command prompt (or just prompt) is a sequence of (one or more) characters used in a command line interface to indicate availability to accept commands. Command prompts usually end with one of the characters $, #, :, > and often include other information, such as the path of the current working directory.

It is common for prompts to be modifiable by the user. Depending on the environment, they may include colors, special characters, and other elements like the current time, in order, for instance, to make the prompt more informative or visually pleasing, or to easily distinguish sessions on various machines.

In MS-DOS and in the Windows command line interpreter the prompt is modifiable by issuing a prompt command or by changing the value of the %PROMPT% environment variable. The default C:\> style is obtained, for instance, with "prompt $P$G".

On Unix systems, the $PS1 variable can be used, although other variables also may have an impact on what appears on the screen (depending on what shell is being used). In the bash shell, a prompt of the form

[time] user@host: work_dir $

could be set by issuing the command

export PS1='[\t] \u@\H: $(pwd) $'

[edit] CLI vs GUI

Ever since graphical user interfaces were developed, some people have argued that command line interfaces are not beneficial anymore. One thing to keep in mind is that graphics and a command line are orthogonal: there are also text user interfaces on one hand and on the other hand, graphics applications such as CADs using a command line. The controversy appears purest between textual and graphical operating system shells, but it's typically generalized to the level of textual commands versus WIMP interaction. A coarse characterization is that GUI applications are simple to learn but CLI applications are powerful if learned.

The command line interface is often attacked with arguments such as:

1. Commands must be remembered or looked up in a manual. This means that users of command-line programs must memorize a great deal of specific information (with little importance outside the program), or keep consulting documentation. If one forgets the exact syntax of the command for what they need to do, they will spend time looking for it in documentation.
2. GUIs, on the other hand, conventionally present all the available functionality in a hierarchical manner through menus, toolbars, dialogs and other graphical means. They do not require the user to memorize the conventions to supply command-line options, because they allow these options to be entered via graphical methods (and usually restrict the range of values that can be entered to valid ones).

Rebuttals include:

1. The complex menu hierarchies and vast preferences dialogs of large GUI applications, plus visually non-discoverable actions, necessitate consulting of documentation to achieve tasks. To alleviate this, Microsoft has for instance introduced Ribbons in Microsoft Office 2007.
2. GUIs often change the meaning or location of a command or icon due to the context of the use at the time of usage. For example, Office 2003 moves more recently used commands into the initial selection visible in the menu, so the statement "Click Edit, then the third one down is Paste" may be different from one machine to the next. Because this behavior seems annoying to some users, it could be turned off. Pulling an icon onto the trash can on the Mac OS prior to OS X can mean delete the files, or eject the disk.
3. CLIs allow the human to use language skills instead of limiting the interaction to pointing. ^[1]
4. CLI environments consume far less resources than GUIs and can be used far more efficiently when armed with the knowledge of a CLI environment.
5. Because all CLI applications use standard I/O (stdio), they can easily work together in a script, furthermore, it's easier to describe one's problem, just by copying and pasting in your message the sequence of commands you did. It's also easier to search for similar problems in the Internet, as the CLI are more normalized and often don't depend on localization.
6. Repetitive tasks can be easily achieved with loops, which would take hours in a GUI environment.
7. Background tasks can be processed as a batch or on a timer, without taking over the users' only control mechanism, and without determining the positions of GUI elements.

The main advantage of CLIs versus GUIs and the reason that they enhance productivity is that, by the way they work, all actions have a name, and therefore a series of actions can be written in a shell script. This means that a user of a CLI can put strings of commands which achieve some desired effect into a holder, and can give that holder to another program, or even itself. ("Here, use this that I just made."), while a GUI user would have to detail a lengthy description ("First go to this menu, click that button, look for the 'advanced properties' tab...") As those commands are difficult to write, and difficult to understand for a human being, we could perhaps say that CLI is worse than GUI for simple tasks like opening a file with en editor, while CLI is better than GUI for complex, repetitive tasks that can be programmed.

As for instance, a programmer or system administrator will rather write a script to convert 753 GIF files into JPG than convert them one by one by repeating the same 753 series of mouse clicks with an intuitive, user-friendly GUI. A CLI is basically a wizard's tool.

The above paragraphs give an opinion which does not take into account the following points:

1. A GUI has the ability to give the user a much broader view of what is happening in the system. If I look, as an example, at the main window of my mail client, I can see the information about how many e-mails are in which folders, how many of them are unread, what e-mails are in the selected folder(s), what is the program doing right now, is it getting mail, is it sending mail, are there any network problems and so on without any interaction, I can decide with a glance at the respective part of the GUI. A CLI or command line program would have difficulties with displaying so much information without being confusing due to the lack of a graphics capabilities.
2. A GUI could be more efficient in user interaction because of its modes. A CLI application which is strictly mode-less at the user prompt needs more information from the user than a GUI in a certain state. If I want, for example, to create a new folder and open that new folder on the spot, in a CLI environment, I have to type e.g. "mkdir <name>" followed by a stroke or return and another command to change to that directory. Even if shortcuts are used so that one does not have to enter the name of the folder twice, we have to tell the command line again which folder we want to change to. On the other hand, in a GUI, as an example with the Mac OS Finder, I press Command-N, type in the Name and then I press Command-O to open the Folder. In Windows, the GUI automatically assigns the name "Copy of x" when a file or directory called "x" is copied to the same location as the original, avoiding the error "Duplicate name" or the potential issue of creating a file with no name, or a (probably meaningless to the user) system-based name.
3. Just because a GUI has no CLI does not mean that it is not scriptable. Again the Mac OS with AppleScript has a standard interface to applications which lets them talk to each other, but which acts at a much higher lever. As it is only possible on the command line to transfer data as text or in form of binary files which have to be written to disk, AppleScript lets applications form whole "chunks" of information bundled with metadata and send them as a whole. Also a CLI is non-interactive, so there is always a new instance of the called program to be launched, which is less economic in terms of resources. (However, a CLI will have a lower footprint in RAM compared to a GUI, especially a GUI which already has all the programs required loaded and ready.) Other platforms offer equivalent mechanisms for scripting GUI applications. There are even IDEs which let a user build a script to say convert 754 GIF-files into PNG-format without even touching the keyboard. However, these generally utilise the underlying CLI.
4. As there are doubtless more efficient ways to use a computer than just moving a mouse around, only using command line interface is the other extreme. A experienced GUI-user would have his "tricks" and "shortcuts" to tell the computer what he is wanting to do, like short function keys and utilities which opens a specific program by pressing a combination of keys, or a few keys in sequence. There are several utilities which perform a specific task and are, once written, far more efficient than writing a complete shell script. These fall part-way between both camps.

Some applications provide both a CLI and a GUI. One example is the CAD program AutoCAD, which enable users to quickly access program features using keystrokes instead of point and click methodology. The engineering/scientific numerical computation package MATLAB provides no GUI for some calculations, but the CLI can handle any calculation. The three-dimensional-modelling program Rhinoceros 3D (used to design the cases of most cell phones, as well as thousands of other industrial products) provides a CLI (whose language, by the way, is distinct from Rhino's scripting language). In some computing environments, such as the Oberon or Smalltalk user interface, most of the text which appears on the screen may be used for giving commands.

[edit] References

1. ^ Don Gentner and Jakob Nielsen. The Anti-Mac Interface. http://acm.org/cacm/AUG96/antimac.htm

[edit] See also

• In the Beginning...was the Command Line
• Scripting language

[edit] External links

• Linux Command Line — a list of unix shell commands.
• Command Line Warriors — an open site about Command Line Computing.
• The Interaction-Design.org Encyclopedia entry on Interaction Styles, comparing Command Line Interfaces with other Interaction Styles
• Coming Soon to Windows: The Microsoft Shell (MSH) by Jason Nadal
• Command lines versus GUIs
• The Windows XP Command Line, Batch Files, and Scripting
• "GetPot. Object oriented command line parsing." Library available for C++, Python, Java, and Ruby.
• "Object-Oriented Command Line Interfaces" — Article describing the use of the TE-Common CLI library for Java (also available for .NET).
• PHP Command Line Interface — All about PHP CLI SAPI (using PHP in command line).
• - Setting up the console for Windows - A basic guide to setting up and using the command line for Windows.