A command-line interface (CLI) is a means of interacting with a device or computer program with
Operating system command-line interfaces are often implemented with command-line interpreters or command-line processors. Programs with command-line interfaces are generally easier to automate via scripting. Many software systems implement command-line interfaces for control and operation. This includes programming environments and utility programs.
Today, many users rely upon
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
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 include
Although the term 'shell' is often used to describe a command-line interpreter, strictly speaking, a 'shell' can be any program that constitutes the user-interface, including fully graphically oriented ones. For example, the default Windows GUI is a shell program named
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
In Colossal Cave Adventure from 1975, the user uses a CLI to enter one or two words to explore a cave system.
The command-line interface evolved from a form of communication conducted by people over teleprinter (TTY) 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
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.
Early microcomputers themselves were based on a command-line interface such as
In November 2006,
Since 2001, the
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
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
Anatomy of a shell CLI
This section needs additional citations for verification. (July 2015))
The general pattern of a command line interface is:
Prompt command param1 param2 param3 … paramN
- Prompt — generated by the program to provide context for the user.
- Command — provided by the user. Commands are usually one of three classes:
- Internal commands are recognized and processed by the command line interpreter.
- Included commands run separate executables.
- External commands run executable files that may be included by other parties.[clarification needed]
- param1 …paramN — parameters provided by the user. The format and meaning of the parameters depends upon the command. In the case of Included or 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.
A CLI can generally be considered as consisting of
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
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
where doSomething is, in effect, a
>>will redirect the output and append it to the file. Another redirection operator is the vertical bar (
|), which creates a pipeline
CLI and resource protection
One can modify the set of available commands by modifying which paths appear in the PATH environment variable. Under Unix, commands also need be marked as executable files. The directories in the path variable are searched in the order they are given. By re-ordering the path, one can run e.g. \OS2\MDOS\E.EXE instead of \OS2\E.EXE, when the default is the opposite. Renaming of the executables also works: people often rename their favourite editor to EDIT, for example.
The command line allows one to restrict available commands, such as access to advanced internal commands. The Windows
Some CLIs, such as those in
A command prompt (or just prompt) is a sequence of (one or more) characters used in a command-line interface to indicate readiness to accept commands. It literally prompts the user to take action. A prompt usually ends with one of the characters
- and often includes other information, such as the path of the current working directory and the hostname.
On many Unix and derivative systems, the prompt commonly ends in
% if the user is a normal user, but in
# if the user is a superuser ("root" in Unix terminology).
End-users can often modify prompts. Depending on the environment, they may include colors, special characters, and other elements (like variables and functions for the current time, user, shell number or working directory) in order, for instance, to make the prompt more informative or visually pleasing, to distinguish sessions on various machines, or to indicate the current level of nesting of commands. On some systems, special tokens in the definition of the prompt can be used to cause external programs to be called by the command-line interpreter while displaying the prompt.
In DOS' COMMAND.COM and in Windows NT's
C:\>style is obtained, for instance, with
PROMPT $P$G. The default of older DOS systems,
C>is obtained by just
PROMPT, although on some systems this produces the newer
C:\>style, unless used on floppy drives A: or B:; on those systems
PROMPT $N$Gcan be used to override the automatic default and explicitly switch to the older style.
Many Unix systems feature the
$PS1 variable (Prompt String 1), although other variables also may affect the prompt (depending on the shell used). In the Bash shell, a prompt of the form:
[time] [email protected]: work_dir $
could be set by issuing the command
export PS1='[\t] \u@\H: \W $'
$RPROMPTvariable controls an optional "prompt" on the right-hand side of the display. It is not a real prompt in that the location of text entry does not change. It is used to display information on the same line as the prompt, but right-justified.
In RISC OS the command prompt is a
* symbol, and thus (OS) CLI commands are often referred to as "star commands". One can also access the same commands from other command lines (such as the BBC BASIC command line), by preceding the command with a
A command-line argument or parameter is an item of information provided to a program when it is started. A program can have many command-line arguments that identify sources or destinations of information, or that alter the operation of the program.
When a command processor is active a program is typically invoked by typing its name followed by command-line arguments (if any). For example, in Unix and Unix-like environments, an example of a command-line argument is:
"file.s" is a command-line argument which tells the program rm to remove the file "file.s".
Some programming languages, such as
sys.argvfor "command-line arguments".
A command-line option or simply option (also known as a flag or switch) modifies the operation of a command; the effect is determined by the command's program. Options follow the command name on the command line, separated by spaces. A space before the first option is not always required, such as
DIR /? in DOS, which have the same effect of listing the DIR command's available options, whereas
dir --help (in many versions of Unix) does require the option to be preceded by at least one space (and is case-sensitive).
The format of options varies widely between operating systems. In most cases the syntax is by convention rather than an operating system requirement; the entire command line is simply a string passed to a program, which can process it in any way the programmer wants, so long as the interpreter can tell where the command name ends and its arguments and options begin.
A few representative samples of command-line options, all relating to listing files in a directory, to illustrate some conventions:
|Operating system||Command||Valid alternative||Notes|
||instruct the directory command to also display the ownership of the files.|
Note the Directory command name is not case sensitive, and can be abbreviated to as few letters as required to remain unique.
||display ownership of files whose names begin with "D", sorted by size, smallest first.|
Note spaces around argument d* are required.
||display in long format files and directories beginning with "D" (but not "d"), sorted by size (largest first).|
Note spaces are required around all arguments and options, but some can be run together, e.g. -lS is the same as -l -S.
|Data General RDOS CLI||
||list every attribute for files created before 26 April 1980.|
Note the /B at the end of the date argument is a local switch, that modifies the meaning of that argument, while /S and /E are global switches, i.e. apply to the whole command.
In some other systems abbreviations are automatic, such as permitting enough of the first characters of a command name to uniquely identify it (such as
SU as an abbreviation for
SUPERUSER) while others may have some specific abbreviations pre-programmed (e.g.
alias md mkdir in tcsh
Option conventions in DOS, Windows, OS/2
On DOS, OS/2 and Windows, different programs called from their COMMAND.COM or CMD.EXE (or internal their commands) may use different syntax within the same operating system. For example:
- Options may be indicated by either of the "switch characters":
-, or either may be allowed. See below.
- They may or may not be case-sensitive.
- Sometimes options and their arguments are run together, sometimes separated by whitespace, and sometimes by a character, typically
Prog -f Filename,
- Some programs allow single-character options to be combined; others do not. The switch
-fAmay mean the same as
-f -A, or it may be incorrect, or it may even be a valid but different parameter.
However, many programs are hardwired to use
/ only, rather than retrieving the switch setting before parsing command-line arguments. A very small number, mainly ports from Unix-like systems, are programmed to accept "-" even if the switch character is not set to it (for example
ping, supplied with Microsoft Windows, will accept the /? option to list available options, and yet the list will specify the "-" convention).
Option conventions in Unix-like systems
This section needs additional citations for verification. (July 2021))
In Unix-like systems, the ASCII hyphen-minus begins options; the new (and GNU) convention is to use two hyphens then a word (e.g.
--create) to identify the option's use while the old convention (and still available as an option for frequently-used options) is to use one hyphen then one letter (e.g.,
-c); if one hyphen is followed by two or more letters it may mean two options are being specified, or it may mean the second and subsequent letters are a parameter (such as filename or date) for the first option.
Two hyphen-minus characters without following letters (
--) may indicate that the remaining arguments should not be treated as options, which is useful for example if a file name itself begins with a hyphen, or if further arguments are meant for an inner command (e.g., sudo). Double hyphen-minuses are also sometimes used to prefix "long options" where more descriptive option names are used. This is a common feature of GNU software. The getopt function and program, and the getopts command are usually used for parsing command-line options.
Unix command names, arguments and options are case-sensitive (except in a few examples, mainly where popular commands from other operating systems have been ported to Unix).
Option conventions in other systems
CP/M typically used
Conversational Monitor System (CMS) uses a single left parenthesis to separate options at the end of the command from the other arguments. For example, in the following command the options indicate that the target file should be replaced if it exists, and the date and time of the source file should be retained on the copy:
COPY source file a target file b (REPLACE OLDDATE
Data General's CLI under their RDOS, AOS, etc. operating systems, as well as the version of CLI that came with their Business Basic, uses only
/ as the switch character, is case-insensitive, and allows "local switches" on some arguments to control the way they are interpreted, such as
MAC/U LIB/S A B C $LPT/L has the global option "U" to the macro assembler command to append user symbols, but two local switches, one to specify LIB should be skipped on pass 2 and the other to direct listing to the printer, $LPT.
Built-in usage help
One of the criticisms of a CLI is the lack of cues to the user as to the available actions. In contrast, GUIs usually inform the user of available actions with menus, icons, or other visual cues. To overcome this limitation, many CLI programs display a usage message, typically when invoked with no arguments or one of
However, entering a program name without parameters in the hope that it will display usage help can be hazardous, as programs and scripts for which command line arguments are optional will execute without further notice.
Although desirable at least for the help parameter, programs may not support all option lead-in characters exemplified above.
Under DOS, where the default command-line option character can be changed from
-, programs may query the
-and therefore the
/character is accepted as alternative path delimiter also at the DOS command line, programs may misinterpret options like
/Has paths rather than help parameters. However, if given as first or only parameter, most DOS programs will, by convention, accept it as request for help regardless of the current SwitChar setting.
In some cases, different levels of help can be selected for a program. Some programs supporting this allow to give a verbosity level as an optional argument to the help parameter (as in
/H:2, etc.) or they give just a short help on help parameters with question mark and a longer help screen for the other help options.
Depending on the program, additional or more specific help on accepted parameters is sometimes available by either providing the parameter in question as an argument to the help parameter or vice versa (as in
/H:W or in
/W would be another parameter supported by the program)).[nb 1]
In a similar fashion to the help parameter, but much less common, some programs provide additional information about themselves (like mode, status, version, author, license or contact information) when invoked with an "about" parameter like
! characters typically also serve other purposes at the command line, they may not be available in all scenarios, therefore, they should not be the only options to access the corresponding help information.
If more detailed help is necessary than provided by a program's built-in internal help, many systems support a dedicated external "
help command" command (or similar), which accepts a command name as calling parameter and will invoke an external help system.
In the DR-DOS family, typing
/H at the
Command description syntax
Built-in usage help and man pages commonly employ a small syntax to describe the valid command form:[nb 2]
- angle brackets for required parameters:
- square brackets for optional parameters:
mkdir [-p] <dirname>
- ellipses for repeated items:
cp <source1> [source2…] <dest>
- vertical bars for choice of items:
Notice that these characters have different meanings than when used directly in the shell. Angle brackets may be omitted when confusing the parameter name with a literal string is not likely.
The space character
In many areas of computing, but particularly in the command line, the
_), or by enclosing a name with embedded spaces between quote characters or using an escape character before the space, usually a backslash
\). For example
Long path/Long program name Parameter one Parameter two…
is ambiguous (is "program name" part of the program name, or two parameters?); however
Long_path/Long_program_name Parameter_one Parameter_two…,
LongPath/LongProgramName ParameterOne ParameterTwo…,
"Long path/Long program name" "Parameter one" "Parameter two"…
Long\ path/Long\ program\ name Parameter\ one Parameter\ two…
are not ambiguous. Unix-based operating systems minimize the use of embedded spaces to minimize the need for quotes. In Microsoft Windows, one often has to use quotes because embedded spaces (such as in directory names) are common.
Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command. Because it must satisfy both the interactive and programming aspects of command execution, it is a strange language, shaped as much by history as by design.
The term command-line interpreter (CLI) is applied to computer programs designed to interpret a sequence of lines of text which may be entered by a user, read from a file or another kind of data stream. The context of interpretation is usually one of a given operating system or programming language.
Command-line interpreters allow users to issue various commands in a very efficient (and often terse) way. This requires the user to know the names of the commands and their parameters, and the syntax of the language that is interpreted.
#! mechanism and OS/2 EXTPROC command facilitate the passing of batch files to external processors. One can use these mechanisms to write specific command processors for dedicated uses, and process external data files which reside in batch files.
Many graphical interfaces, such as the OS/2 Presentation Manager and early versions of Microsoft Windows use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shell[clarification needed] or in files like the registry or the OS/2
The earliest computers did not support interactive input/output devices, often relying on sense switches and lights to communicate with the computer operator. This was adequate for batch systems that ran one program at a time, often with the programmer acting as operator. This also had the advantage of low overhead, since lights and switches could be tested and set with one machine instruction. Later a single system console was added to allow the operator to communicate with the system.
From the 1960s onwards, user interaction with computers was primarily by means of command-line interfaces, initially on machines like the
All of these devices were purely text based, with no ability to display graphic or pictures.[nb 3] For business application programs, text-based menus were used, but for more general interaction the command line was the interface.
From the early 1970s the
The command-line was also the main interface for the early home computers such as the
The command-line was first seriously challenged by the
Modern usage as an operating system shell
While most non-expert computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:
- The default VAX/VMS command shell, using the DCL language, has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite. Unix command shells have been ported to VMS and DOS/Windows 95 and Windows NT types of operating systems.
- ROM-DOS, and FreeDOS.
- Windows Resource Kit and Windows Services for UNIX include Korn and the Bourne shells along with a Perl interpreter (Services for UNIX contains ActiveState ActivePerl in later versions and Interix for versions 1 and 2 and a shell compiled by Microsoft)
- IBM OS/2 (and derivatives such as REXX.
- cmd.exe is part of the Windows NT stream of operating systems.
- Yet another cmd.exe is a stripped-down shell for Windows CE3.0.
- An MS-DOS type interpreter called PocketDOS has been ported to Windows CE machines; the most recent release is almost identical to MS-DOS 6.22 and can also run Windows 1, 2, and 3.0, QBasic and other development tools, 4NT and 4DOS. The latest release includes several shells, namely MS-DOS 6.22, PC DOS 7, DR DOS 3.xx, and others.
- Windows users might use the zsh, psh
- Implementations of PHP have a shell for interactive use called php-cli.
- Standard Tcl/Tkhas two interactive shells, Tclsh and Wish, the latter being the GUI version.
- Python, Ruby, Lua, XLNT, and other interpreters also have command shells for interactive use.
- FreeBSD uses tcsh as its default interactive shell for the superuser, and ash as default scripting shell.
- Many Linux distributions have the Bash implementation of the Unix shell.
- Apple macOS and some Linux distributions use zsh. Previously, macOS used tcsh and Bash.
- Android uses the mksh shell, which replaces a shell derived from ash that was used in older Android versions, supplemented with commands from the separate toolbox binary.
- Routers with Junosand many others are commonly configured from the command line.
- The Plan 9 operating system uses the rc shell which is similar in design to the Bourne shell.
Most command-line interpreters support
Other command-line interfaces
The command line provides an interface between programs as well as the user. In this sense, a command line is an alternative to a dialog box. Editors and databases present a command line, in which alternate command processors might run. On the other hand, one might have options on the command line, which opens a dialog box. The latest version of 'Take Command' has this feature. DBase used a dialog box to construct command lines, which could be further edited before use.
Programs like BASIC, diskpart, Edlin, and QBASIC all provide command-line interfaces, some of which use the system shell. Basic is modeled on the default interface for 8-bit Intel computers. Calculators can be run as command-line or dialog interfaces.
Emacs provides a command-line interface in the form of its minibuffer. Commands and arguments can be entered using Emacs standard text editing support, and output is displayed in another buffer.
There are a number of text mode games, like
The most notable of these interfaces is the standard streams interface, which allows the output of one command to be passed to the input of another. Text files can serve either purpose as well. This provides the interfaces of piping, filters and redirection. Under Unix, devices are files too, so the normal type of file for the shell used for stdin,stdout and stderr is a tty device file.
Another command-line interface allows a shell program to launch helper programs, either to launch documents or start a program. The command is processed internally by the shell, and then passed on to another program to launch the document. The graphical interface of Windows and OS/2 rely heavily on command-lines passed through to other programs – console or graphical, which then usually process the command line without presenting a user-console.
Programs like the OS/2 E editor and some other IBM editors, can process command-lines normally meant for the shell, the output being placed directly in the document window.
A web browser's URL input field can be used as a command line. It can be used to "launch"
- Comparison of command shells
- List of command-line interpreters
- Console application
- Interpreter directive
- Read-eval-print loop
- Shell script
- Run command
- Graphical user interface § Comparison to other interfaces
- In the Beginning... Was the Command Line
- ^ Notable difference for describing the command syntax of DOS-like operating systems: Windows Server 2003 R2 documentation uses italic letters for “information that the user must supply", but Windows Server 2008 documentation uses angle brackets. Italics can not be displayed by the internal "help” command, while there is no problem with angle brackets.
- ^ With the exception of ASCII art.
- ^ "Unix Shells". Archived from the original on 2007-11-08.
the notion of having a replaceable "command shell" rather than a "monitor" tightly integrated with the OS kernel tends to be attributed to Multics.
- ^ a b "The Origin of the Shell". www.multicians.org. Retrieved 2017-04-12.
- ^ Metz, Cade (2013-01-03). "Say Bonjour to the Internet's Long-Lost French Uncle". Wired. Retrieved 2017-07-31.
- ^ Mazières, David (Fall 2004). "MULTICS - The First Seven Years". Advanced Operating Systems. Stanford Computer Science Department. Retrieved 2017-08-01.
- ^ a b Jones, M. (2011-12-06). "Evolution of shells in Linux". developerWorks. IBM. Retrieved 2017-08-01.
- ^ "GNU BASH Reference".
- ^ "Microsoft Windows Command Shell Overview".
- ^ SID Users Guide (PDF). Digital Research. 1978. 595-2549. Archived (PDF) from the original on 2019-10-20. Retrieved 2020-02-06. (4+69 pages)
- ^ SID-86 User's Guide for CP/M-86 (2 ed.). Digital Research. August 1982 [March 1982]. SID86UG.WS4. Archived from the original on 2019-10-20. Retrieved 2020-02-06.  (NB. A retyped version of the manual by Emmanuel Roche with Q, SR, and Z commands added.)
- ^ OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.)
- ISBN 978-111816632-1.
The shell has four different command prompts, called PS1, P52, P53, and PS4. PS stands for Prompt String.
- Acorn Computers Limited. 1992-03-01. p. 125.
- ^ 4DOS 8.00 online help.
- Caldera, Inc. Archived from the originalon 2019-04-08. Retrieved 2019-04-08.
- Caldera, Inc. 1998-12-24. Archived from the originalon 2019-04-08. Retrieved 2019-04-08.
- ^ "Argument Syntax (The GNU C Library)". www.gnu.org. Retrieved 2021-07-09.
- ^ a b c Paul, Matthias R. (2002-05-13). "[fd-dev] mkeyb". freedos-dev. Archived from the original on 2018-09-10. Retrieved 2018-09-10.
[…] CPI /H […] CPI [@] [@] [/?|/Help[:topic]] [/!|/About] […] [?|&] […] /?, /Help Display this help screen or specific help for a topic (+) […] /!, /About Display the 'About' info screen […] /Cpifile (+) .CPI/.CP file name <EGA.CPI>; extension: <.CPI>; CPI.EXE=StdIn […] /Report Report file name <'
'=StdOut>; extension: <.RPT> […] /Style (+) Export <0>-6=BIN-raw/ROM/RAM/PSF0/1/SH/CHED; 7-12/13-18/19-24=ASM-hex/dec/bin/ip/il/p/l/mp/ml […] CPI /H:C […] Overview on codepage file parameter usage: […] CPI /H:S […] Overview on /Style parameters: […] ?, & Online edit mode (prompts for additional parameter input) […]
- ^ DEBUG is still based on the old SID86.EXE, I suggest to run DEBUG 1.51 and enter the extended help system with ?? from the debug prompt. This will give you eight screens full of syntax and feature help. Some of these features were also supported by older issues. […]
- ^ a b Paul, Matthias R.; Frinke, Axel C. (2006-01-16). FreeKEYB - Advanced international DOS keyboard and console driver (User Manual) (v7 preliminary ed.).
- Concurrent Controls, Inc. (CCI). 1997-02-10. HELP.HLP. (NB. The symbolic instruction debugger SID86provides a short help screen on
?and comprehensive help on
- ^ Paul, Matthias R. (1997-05-24) . DRDOSTIP.TXT – Tips und Tricks für DR DOS 3.41 - 5.0. MPDOSTIP (in German) (47 ed.). Archived from the original on 2016-11-07. Retrieved 2016-11-07.
- ^ "The Open Group Base Specifications Issue 7, Chapter 12.1 Utility Argument Syntax". The Open Group. 2008. Retrieved 2013-04-07.
man-pages(7)– Linux Conventions and Miscellany Manual (NB. Conventions for describing commands on Unix-like operating systems.)
- ^ "Command shell overview". Windows Server 2003 Product Help. Microsoft. 2005-01-21. Retrieved 2013-04-07.
- ^ "Command-Line Syntax Key". Windows Server 2008 R2 TechNet Library. Microsoft. 2010-01-25. Retrieved 2013-04-07.
- ISBN 0-13-937699-2.
- ^ Pouzin, Louis. "The Origin of the Shell". Multicians.org. Retrieved 2013-09-22.
- ^ "Remembering Windows 95's launch 15 years later". 2010-08-24.
- ^ "A history of Windows". windows.microsoft.com. Archived from the original on 2015-03-01.
- ^ "Windows POSIX shell compatibility".
- ^ "master - platform/external/mksh - Git at Google". android.googlesource.com. Retrieved 2018-03-18.
- ^ "Android adb shell - ash or ksh?". stackoverflow.com. Retrieved 2018-03-14.
- ^ "Android sh source". GitHub. Archived from the original on 2012-12-17.
- ^ "Android toolbox source". GitHub.
- ^ "Configuration Fundamentals Configuration Guide, Cisco IOS Release 15M&T". Cisco. 2013-10-30. Using the Command-Line Interface.
The Cisco IOS command-line interface (CLI) is the primary user interface…
- ^ "Command-Line Interface Overview". www.juniper.net. Retrieved 2018-03-14.
- ^ "Google strange goodness".
- ^ jQuery Terminal Emulator
- ^ DuckDuckGo TTY
- The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.
- Command-Line Reference: Microsoft TechNet Database "Command-Line Reference"