Command-line interface
A command-line interface, sometimes called a command-line shell, is a means of interacting with software via commands each formatted as a line of text. Command-line interfaces emerged in the mid-1960s, on computer terminals, as an interactive and more user-friendly alternative to the non-interactive mode available with punched cards.
For nearly three decades, a CLI was the most common interface for software, but today a graphical user interface is more common. Nonetheless, many programs such as operating system and software development utilities still provide CLI.
A CLI enables automating programs since commands can be stored in a script file that can be used repeatedly. A script allows its contained commands to be executed as a group.
A CLI is made possible by command-line interpreters or command-line processors, which are programs that execute input commands.
Alternatives to a CLI include a GUI, text-based menuing, and keyboard shortcuts.
Comparison to graphical user interfaces
Compared with a graphical user interface, a command-line interface requires fewer system resources to implement. Since [|options] to commands are given in a few characters in each command line, an experienced user often finds the options easier to access. Automation of repetitive tasks is simplified by line editing and history mechanisms for storing frequently used sequences; this may extend to a scripting language that can take parameters and variable options. A command-line history can be kept, allowing review or repetition of commands.A command-line system may require paper or online manuals for the user's reference, although often a help option provides a concise review of the options of a command. The command-line environment may not provide graphical enhancements such as different fonts or extended edit windows found in a GUI. It may be difficult for a new user to become familiar with all the commands and options available, compared with the icons and drop-down menus of a graphical user interface, without reference to manuals.
Types
Operating system command-line interfaces
Operating system command-line interfaces are usually distinct programs supplied with the operating system. A program that implements such a text interface is often called a command-line interpreter, command processor or shell.Examples of command-line interpreters are Nushell, DEC's DIGITAL Command Language in OpenVMS and, the various Unix shells, 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. Under most operating systems, it is possible to replace the default shell program with alternatives; examples include 4DOS for DOS, 4OS2 for OS/2, and 4NT / Take Command for Windows.
Although the term shell is often used to describe a command-line interpreter, strictly speaking, a shell is a command interpreter and processor and by extension a program that provides an interface to a command interpreter and processor and to the broad capabilities of the operating system. For example, the default Windows GUI is a shell GUI named EXPLORER.EXE, as defined in the SHELL=EXPLORER.EXE line in the WIN.INI configuration file. This program strictly speaking is a shell GUI and by extension a shell, but it is not a CLI nor a shell CLI.
Application command-line interfaces
Application programs may also have command-line interfaces.An application program may support none, any, or all of these three major types of command-line interface mechanisms:
- Parameters: Most command-line interfaces support a means to pass additional information to a program when it is launched.
- Interactive command-line sessions: After launch, a program may provide an operator with an independent means to enter commands.
- Inter-process communication: Most operating systems support means of inter-process communication. Command lines from client processes may be redirected to a CLI program by one of these methods.
In Colossal Cave Adventure from 1975, the user uses a CLI to enter one or two words to explore a cave system.
History
The command-line interface evolved from a form of communication conducted by people over teleprinter machines. Sometimes these involved sending an order or a confirmation using telex. Early computer systems often used teleprinter as the means of interaction with an operator.The mechanical teleprinter was replaced by a "glass tty", a keyboard and screen emulating the teleprinter. "Smart" terminals permitted additional functions, such as cursor movement over the entire screen, or local editing of data on the terminal for transmission to the computer. As the microcomputer revolution replaced the traditionalminicomputer + terminalstime sharing architecture, hardware terminals were replaced by terminal emulators — PC software that interpreted terminal signals sent through the PC's serial ports. These were typically used to interface an organization's new PC's with their existing mini- or mainframe computers, or to connect PC to PC. Some of these PCs were running Bulletin Board System software.
Early operating system CLIs were implemented as part of resident monitor programs, and could not easily be replaced. The first implementation of the shell as a replaceable component was part of the Multics time-sharing operating system. In 1964, MIT Computation Center staff member Louis Pouzin developed the RUNCOM tool for executing command scripts while allowing argument substitution. Pouzin coined the term shell to describe the technique of using commands like a programming language, and wrote a paper about how to implement the idea in the Multics operating system. Pouzin returned to his native France in 1965, and the first Multics shell was developed by Glenda Schroeder.
File:Version 7 UNIX SIMH PDP11 Kernels Shell.png|thumb|250px|Bourne shell interaction on Version 7 Unix
The first Unix shell, the V6 shell, was developed by Ken Thompson in 1971 at Bell Labs and was modeled after Schroeder's Multics shell. The Bourne shell was introduced in 1977 as a replacement for the V6 shell. Although it is used as an interactive command interpreter, it was also intended as a scripting language and contains most of the features that are commonly considered to produce structured programs. The Bourne shell led to the development of the KornShell, Almquist shell, and the popular Bourne-again shell.
Early microcomputers themselves were based on a command-line interface such as CP/M, DOS or AppleSoft BASIC. During the 1980s and 1990s, the introduction of the Apple Macintosh and of Microsoft Windows on PCs saw the command line interface as the primary user interface replaced by the Graphical User Interface. The command line remained available as an alternative user interface, often used by system administrators and other advanced users for system administration, computer programming and batch processing.
In November 2006, Microsoft released version 1.0 of Windows PowerShell, which combined features of traditional Unix shells with their proprietary object-oriented.NET Framework. MinGW and Cygwin are open-source packages for Windows that offer a Unix-like CLI. Microsoft provides MKS Inc.'s ksh implementation MKS Korn shell for Windows through their Services for UNIX add-on.
Since 2001, the Macintosh operating system macOS has been based on a Unix-like operating system called Darwin. On these computers, users can access a Unix-like command-line interface by running the terminal emulator program called Terminal, which is found in the Utilities sub-folder of the Applications folder, or by remotely logging into the machine using ssh. Z shell is the default shell for macOS; Bash, tcsh, and the KornShell are also provided. Before macOS Catalina, Bash was the default.
Usage
A CLI is used whenever a large vocabulary of commands or queries, coupled with a wide range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with operating system command shells. CLIs are also used by systems with insufficient resources to support a graphical user interface. Some computer language systems provide an interactive command-line mode to allow for rapid evaluation of code.CLIs are often used by programmers and system administrators, in engineering and scientific environments, and by technically advanced personal computer users. CLIs are also popular among people with visual disabilities since the commands and responses can be displayed using refreshable Braille displays.
Anatomy of a shell CLI
The general pattern of a command line is:prompt command param1 param2 param3 … paramN
- prompt — output by the program to indicate that its ready for input; a prompt may include contextual information and often ends with a symbol that provides a visual cue that input is expected
- command — input by the user, a command is usually one of two classes:
- # Internal commands are recognized and processed by the command line interpreter. Internal commands are also called built-in commands.
- # External commands run executables found in separate executable files. The command line interpreter searches for executable files with names matching the external command.
- param1 …paramN — parameters provided by the user. The format and meaning of the parameters depends upon the command. In the case of external commands, the values of the parameters are delivered to the program as it is launched by the OS. Parameters may be either [|arguments] or options.
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, 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, defines their own proprietary set of rules. These rules also dictate how a user navigates through the system of commands. The semantics define what sort of operations are possible, on what sort of data these operations can be performed, and how the grammar represents these operations and data—the symbolic meaning in the syntax.
Two different CLIs may 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 CLIs without needing to learn anything, as well as to enable re-use of scripts.
A simple CLI will display a prompt, accept a command line typed by the user terminated by the Enter key, then execute the specified command and provide textual display of results or error messages. Advanced CLIs will validate, interpret and parameter-expand the command line before executing the specified command, and optionally capture or redirect its 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. Useful command lines 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 entity, called a command procedure or script which itself can be treated as a command. These advantages mean that a user must figure out a complex command or series of commands only once, because they can be saved, to be used again.
The commands given to a CLI shell are often in one of the following forms:
-
doSomething how toFiles -
doSomething how sourceFile destinationFile -
doSomething how < inputFile > outputFile -
doSomething how | doSomething how | doSomething how > outputFile
> in the third example is a redirection operator, telling the command-line interpreter to send the output of the command not to its own standard output but to the named file. This will overwrite the file. Using >> will redirect the output and append it to the file. Another redirection operator is the vertical bar, which creates a pipeline where the output of one command becomes the input to the next command.