A command-line interface (CLI), also known as a command-line shell, is a means of interacting with software via commands each formatted as a line of text. The concept of interacting with a computer via text evolved over two decades, transitioning from physical hardware to sophisticated software. Before the CLI, computers were programmed using physical switches or punched cards. The shift toward a "command" style interaction began with the use of teleprinters/teletypes. Early systems like the Whirlwind I (1951) at MIT began utilizing typewriter-like inputs for direct control, moving away from batch processing where you'd hand a stack of cards to an operator and wait hours for a result. Devices like the Teletype Model 33, introduced in 1963, allowed operators to type a command and receive a printed response from the computer.
The command-line interpreter emerged when computers became powerful enough to handle multiple users at once, known as time-sharing. The Compatible Time-Sharing System (CTSS), developed in 1961 at MIT, introduced the first true command-line interpreter. For the first time, a user could type a command like LOGIN or PRINT, and a dedicated program (the supervisor) would parse that text and execute the corresponding function. In 1964, Louis Pouzin introduced the software we now recognize as a "shell" for the Multics operating system, providing a programmable environment for executing scripts. Many utilities for operating system management and software development provide CLIs.
Many CLIs enable software automation, 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 (as a single program).
Alternatives to a CLI include a GUI (including the desktop metaphor such as Windows), text-based menuing (including DOS Shell and IBM AIX SMIT), 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 recently or frequently used sequences, allowing review and repetition of commands; this may extend to a scripting language that can take parameters and variable options.
A command-line system may require online or paper 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 (OS) 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 (DCL) in OpenVMS and , the various Unix shells (sh, ksh, csh, tcsh, zsh, Bash, etc.), CCP, DOS' COMMAND.COM, as well as the OS/2 and 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 (either a user interface (command-line interface, GUI, etc...) or a programming 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 (strictly speaking, the Windows shell is shell32.dll not explorer.exe, which is a shell GUI for shell32.dll), but it is not a CLI (command-line interpreter) nor a shell CLI (shell command-line interface).
Application command-line interfaces
Application programs (as opposed to operating systems) 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 (for example, standard streams or named pipes). Command lines from client processes may be redirected to a CLI program by one of these methods.
Some applications support a CLI, presenting their own prompt to the user and accepting command lines. Other programs support both a CLI and a GUI. In some cases, a GUI is simply a wrapper around a separate CLI executable file. In other cases, a program may provide a CLI as an optional alternative to its GUI. CLIs and GUIs often support different functionality. For example, all features of MATLAB, a numerical analysis computer program, are available via the CLI, whereas the MATLAB GUI exposes only a subset of features.
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/teletype (TTY) machines. Sometimes these involved sending an order or a confirmation using telex. Early computer systems often used a teleprinter to interact 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.
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 (ksh), Almquist shell (ash), and the popular Bourne-again shell (or Bash).
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 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 (formerly codenamed Monad), 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 (or arbitrary) 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 (such as Python, Forth, LISP, Rexx, and many dialects of BASIC) provide an interactive command-line mode (generally a read–eval–print loop) 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 separate executables. 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 depend 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.
In this format, the delimiters between command-line elements are whitespace characters and the end-of-line delimiter is the newline delimiter. This is a widely used (but not universal) convention.