View source for Command-line interface

{{distinguish|Text-based user interface}}
{{Use dmy dates|date=August 2012}}
{{Multiple issues|
{{Cleanup|reason=writing style|date=September 2012}}
 {{Refimprove|date=April 2012}}
 {{Original research|date=April 2012}}
}}
[[File:Linux command-line. Bash. GNOME Terminal. screenshot.png|thumb|300px|Screenshot of a sample [[Bash (Unix shell)|Bash]] session. [[GNOME Terminal|GNOME Terminal 3]], [[Fedora 15]]]]
[[File:Apple Unix with Netscape.jpg|thumb|300px|Screenshot of [[Apple Computer]]'s CommandShell in [[A/UX]] 3.0.1.]]
[[File:Windows PowerShell 1.0 PD.png|thumb|300px|Screenshot of [[Windows PowerShell]] 1.0, running on [[Windows Vista]]]]

A '''command-line interface''' ('''CLI'''), also known as '''command-line user interface''', '''console user interface''',<ref>{{cite web|title=Text mode programs (CUI: Console User Interface)|url=https://www.winehq.org/docs/wineusr-guide/cui-programs|work=Wine User Guide|accessdate=Sep 22, 2013}}</ref> and '''character user interface''' ('''CUI'''), is a means of interacting with a [[computer program]] where the [[user (computing)|user]]  (or [[Client (computing)|client]]) issues [[command (computing)|commands]] to the program in the form of successive lines of text (command lines).

The CLI was the primary means of interaction with most computer systems until the introduction of the [[video display terminal]] in the mid-1960s, and continued to be used throughout the 1970s and 1980s on [[Unix]] systems and personal computer systems including [[MS-DOS]], [[*****/M]] and [[Apple DOS]].  The interface is usually implemented with a command line [[Shell (computing)|shell]], which is a program that accepts commands as text input and converts commands to appropriate operating system functions.

Command-line interfaces to computer operating systems are less widely used by casual computer users, who favor [[graphical user interface]]s. Command-line interfaces are often preferred by more advanced computer users, as they often provide a more concise and powerful means to control a program or operating system.

Programs with command-line interfaces are generally easier to automate via [[scripting language|scripting]].

Alternatives to the command line include, but are not limited to [[text user interface]] [[menu (computing)|menus]] (see [[IBM AIX SMIT]] for example), [[keyboard shortcut]]s, and various other [[desktop metaphor]]s centered on the [[pointer (graphical user interfaces)|pointer]] (usually controlled with a [[computer mouse|mouse]]).

==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 (computing)|shell]].  The term 'shell', often used to describe a command-line interpreter, can be in principle any program that constitutes the user-interface, including fully graphically oriented ones&mdash;for example, the default Windows GUI is created by a shell program named EXPLORER.EXE<!-- Not to be confused with Internet Explorer -->, as defined in the SHELL=EXPLORER.EXE line in the WIN.INI configuration file.

Examples of command-line interpreters include the various [[Unix shell]]s (sh, ksh, csh, tcsh, bash, etc.), the historical [[*****/M]] C*****, and [[DOS|MS-DOS/IBM-DOS/DR-DOS]]'s [[COMMAND.COM]], as well as the [[OS/2]] and the Windows [[CMD.EXE]] programs, the latter groups being based heavily on [[Digital Equipment Corporation|DEC's]] [[RSX-11|RSX]] and [[RSTS/E|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]] or [[Take Command (command line interpreter)|Take Command]] for Windows.

==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 operating systems support a means to pass additional information to a program when it is launched. When a program is launched from an OS command line shell, additional text provided along with the program name is passed to the launched program.
# '''Interactive command line sessions''': After launch, a program may provide an operator with an independent means to enter commands in the form of text.
# '''OS inter-process communication''': Most operating systems support means of [[inter-process communication]] (for example; [[standard streams]] or [[named pipe]]s).  Command lines from client processes may be redirected to a CLI program by one of these methods.

===CLI software===
Some applications support only a CLI, presenting a CLI prompt to the user and acting upon command lines as they are entered.  Some examples of CLI-only applications are:
* [[Debug (command)|DEBUG]]
* [[Diskpart]]
* [[Ed (text editor)|Ed]]
* [[Edlin]]
* [[Fdisk]]
* [[Ping (networking utility)|Ping]]

===Hybrid software===
Some computer programs support both a CLI and a GUI. In some cases, a GUI is simply a [[Wrapper function|wrapper]] around a separate CLI [[executable file]]. In other cases, a program may provide a CLI as an optional alternative to its GUI. Both interfaces do not always offer similar functionality. For example, [[MATLAB]], a [[numerical analysis]] computer program, provides no GUI for some calculations, but the CLI can handle any calculation MATLAB supports.

The early Sierra games, like the first three [[King's Quest]] games (1984-1986), use commands from an internal command line to move the character around in the graphic window.

==History==
The command-line interface evolved from a form of dialog once conducted by humans over [[teleprinter]] (TTY) machines, in which human operators remotely exchanged information, usually one line of text at a time.  Early computer systems often used teleprinter machines as the means of interaction with a human operator.  The computer became one end of the human-to-human teleprinter model. So instead of a human communicating with another human over a teleprinter, a human communicated with a computer.

In time, the actual mechanical teleprinter was replaced by a [[dumb terminal#Early VDUs|"glass tty"]] (keyboard and screen, but emulating the teleprinter), and then by a  [[Computer terminal#.22Intelligent.22_terminals|"smart" terminal]] (where a microprocessor in the terminal could address all of the screen, rather than only print successive lines).{{discuss|distinction between dumb/smart terminals}} As the [[microcomputer revolution]] replaced the traditional minicomputer + terminals [[time sharing]] architecture, hardware terminals became replaced by [[terminal emulator]]s - PC software that interpreted terminal signals sent through the PC's [[serial port]]s. 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 microcomputers themselves were based on a command-line interface such as [[*****/M]], [[MS-DOS]] or [[AppleSoft BASIC]]. Throughout the 1980s and 1990s&mdash;especially after the introduction of the [[Apple Macintosh]] and [[Microsoft Windows]]&mdash;command line interfaces were replaced in popular usage by the [[Graphical User Interface]]. The command line remains in use, however, by advanced users for [[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|open-source]] packages for Windows that offer a Unix-like CLI. Microsoft provides [[MKS Inc.]]'s [[Korn shell|ksh]] implementation ''MKS Korn shell'' for Windows through their [[Windows Services for UNIX|Services for UNIX]] add-on.

Since 2001, the [[Macintosh]] operating system is based on a variation of Unix called [[Darwin (operating system)|Darwin]]. On these computers, users can access a Unix-like command-line interface called [[Terminal (Mac OS X)|Terminal]] found in the Applications Utilities folder. This terminal uses [[Bash (Unix shell)|bash]] by default.
[[File:Matlab7.4.png|right|thumb|300px|Screenshot of the [[MATLAB]] 7.4 command-line interface and GUI.]]

==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 shell<!-- please, see [[talk:Shell (computing)]] before changing the link back -->|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 (programming language)|Python]], [[Forth (programming language)|Forth]], [[LISP]], [[Rexx]], and many dialects of [[BASIC]]) 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 disability, since the commands and responses can be displayed using [[Refreshable Braille display]]s.

==Anatomy of a shell CLI==
<!-- These are features of various interpreters WK --->

The general pattern of an OS command line interface is:

[[#Command prompt|prompt]] command param1 param2 param3 ... paramN

* [[#Command prompt|Prompt]] - generated by the program to provide context for the client. 
* Command - provided by the client.  Commands are usually one of three classes:
*# Internal - recognized and processed by the command line interpreter itself and not dependent upon any external executable file.
*# Included - A separate executable file generally considered part of the operating environment and always included with the OS.
*# External - External executable files not part of the basic OS, but added by other parties for specific purposes and applications.
* param1 ...paramN - Optional parameters provided by the client.  The format and meaning of the parameters depends upon the command issued.  In the case of Included or External commands, the values of the parameters are delivered to the program (specified by the Command) as it is launched by the OS.  Parameters may be either [[Argument (computer science)#Parameters and arguments|Arguments]] or [[Command-line option|Options]].

In this example, the delimiters between command line elements are [[whitespace character]]s and the end-of-line delimiter is the [[newline]] delimiter.  This is a widely used (but not universal) convention for command-line interfaces.

<!-- Above is more 'anatomy' and below is a bit mote theory and background and higher level concepts.  Maybe separate sections for both? -->
A CLI can generally be considered as consisting of [[Syntax (programming languages)|syntax]] and [[semantics]]. The ''syntax'' is the grammar that all commands must follow. In the case of [[operating system]]s (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]], defines 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, 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 [[Default (computer science)|defaults]] that can be changed to customize the results.  Useful command lines can be saved by assigning a [[character string]] or [[Alias (command)|alias]] to represent the full command, or several commands can be grouped to perform a more complex sequence&nbsp;– for instance, compile the program, install it, and run it &mdash; 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''

where ''doSomething'' is, in effect, 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 <code>&gt;</code> 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 (the screen) but to the named file. This will overwrite the file. Using <code>&gt;&gt;</code> will redirect the output and append it to the file. Another redirection operator is the [[vertical bar]] (<code>|</code>), which creates a [[pipeline (Unix)|pipeline]] where the output of one command becomes the input to the next command.

=== CLI and resource protection ===
One can modify the set of available commands by modifying which paths appear in the [[PATH (variable)|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 [[CMD.EXE]] does this.  Often, shareware programs will limit the range of commands, including printing a command 'your administrator has disabled running batch files' from the prompt.

Some CLIs, such as those in [[network router]]s, have a hierarchy of [[mode (computer interface)|mode]]s, with a different set of commands supported in each mode. The set of commands are grouped by association with security, system, interface, etc. In these systems the user might traverse through a series of sub-modes. For example, if the CLI had two modes called ''interface'' and ''system'', the user might use the command ''interface'' to enter the interface mode. At this point, commands from the system mode may not be accessible and the user exits the interface mode and enters the system mode.

===Command prompt===
<!-- This section is linked from [[Z shell]], [[Prompt]] and [[Abort, Retry, Fail]] -->
{{Redirect|Command prompt|the Windows component named Command Prompt|cmd.exe}}
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.  Its intent is to literally [[Wiktionary:prompt|prompt]] the user to take action. A prompt usually ends with one of the characters <code>$</code>, <code>%</code>, <code>#</code>, <code>:</code>, <code>&gt;</code> and often includes other information, such as the path of the current [[working directory]].

On many [[Unix]] system and [[Unix-like|derivative systems]], it is common for the prompt to end in a <code>$</code> or <code>%</code> character if the user is a normal user, but in a <code>#</code> character if the user is a [[superuser]] ("root" in Unix terminology).

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 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's COMMAND.COM and in the Windows NT's command-line interpreter [[cmd.exe]] the prompt is modifiable by issuing a <code>prompt</code> command or by directly changing the value of the corresponding <code>%PROMPT%</code> [[environment variable]]. The default of most modern systems, the <code>C:\></code> style is obtained, for instance, with <code>prompt $P$G</code>. The default of older DOS systems, <code>C></code> is obtained by just <code>prompt</code>, although on some systems this produces the newer <code>C:\></code> style, unless used on floppy drives A: or B:; on those systems <code>prompt $N$G</code> can be used to override the automatic default and explicitly switch to the older style.

On many Unix systems, the <code>$PS1</code> variable can be used, although other variables also may have an impact on the prompt (depending on what [[Unix shell|shell]] is being used). In the [[Bash (Unix shell)|bash]] shell, a prompt of the form
:<code>[time] user@host: work_dir $</code>
could be set by issuing the command
:<code>export PS1='[\t] \u@\H: \W $'</code>

In [[zsh]] the <code>$RPROMPT</code> variable 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 <code>*</code> symbol, and thus (OS)CLI commands are often referred to as "star commands".<ref>RISC OS 3 User Guide, Part 3: Outside the desktop (page 125) Published by Acorn Computers Limited, <!-- ISBN 1-85250-124-3 Unable to locate valid metadata in OCLC or LoC -->, Edition 2 Part number 0496,075 Issue 1 March 1992</ref> It is also possible to access the same commands from other command lines (such as the [[BBC BASIC]] command line), by preceding the command with a <code>*</code>.

{{anchor|Arguments_section}}

===Arguments===
[[File:COMMAND LINE.svg|thumb|right|An MS DOS command line, illustrating parsing into command and arguments.]]
A '''command-line argument''' or '''[[Parameter#Computing|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:

<source lang="bash">
rm file.s
</source>

"file.s" is a command-line argument which tells the program [[rm (Unix)|rm]] to remove the file "file.s".

Some programming languages, such as [[C (programming language)|C]], [[C++]] and [[Java (programming language)|Java]], allow a program to interpret the command-line arguments by handling them as string parameters in the [[Main function (programming)|main function]]. Other languages, such as [[Python (programming language)|Python]], expose these arguments as global variables.

In [[Unix-like operating system]]s, a single hyphen-minus by itself is usually a special value specifying that a program should handle data coming from the [[standard input]] or send data to the [[standard output]].

===={{anchor|SwitChar}}Command-line option====
<!-- This section is linked from several places inside or outside this article, preferable by "#SwitChar". Do not remove or rename this section heading without also updating the links. -->
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.

For example, in the [[OpenVMS]] operating system, the command ''directory'' is used to list the [[computer file|file]]s inside a [[directory (file systems)|directory]].  By default&mdash;that is, when the user simply types ''directory''&mdash;it will list only the names of the files.  By appending the ''/owner'' option (to form the command ''directory/owner''), the user can instruct the ''directory'' command to also display the ownership of the files.

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.

In [[Multics]], command-line options and subsystem keywords may be abbreviated. This idea appears to derive from the [[PL/I programming language]], with its shortened keywords (e.g., STRG for STRINGRANGE and DCL for DECLARE). For example, in the Multics "forum" subsystem, the ''-long_subject'' parameter can be abbreviated ''-lgsj''. It is also common for Multics commands to be abbreviated, typically corresponding to the initial letters of the words that are strung together with underscores to form command names, such as the use of ''did'' for ''delete_iacl_dir''.

On DOS, OS/2 and Windows, different programs use different syntax in the same operating system. For example:
* Options may be indicated by <code>-</code>, <code>/</code>, or either.
* 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 <code>:</code> or <code>=</code>; thus <code>Prog -fFilename</code>, <code>Prog -f Filename</code>, <code>Prog -f:Filename</code>, <code>Prog -f=Filename</code>.
* Some programs allow single-character options to be combined; others do not. The switch <code>-fA</code> may mean the same as <code>-f -A</code>, or it may be incorrect, or it may even be a valid but different parameter.

In [[Unix-like]] systems, the ASCII [[hyphen-minus]] is commonly used to specify options. The character is usually followed by one or more letters. Two hyphen-minus characters (<code>--</code>) often 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.

In [[DOS]], [[OS/2]] and [[Windows]], the forward slash (<code>/</code>) is more prevalent, although the hyphen-minus is also sometimes used. [[FlexOS]], [[IBM 4680 OS|4680 OS]] and [[IBM 4690 OS|4690 OS]] use <code>-</code>. [[*****/M]] typically used <code><nowiki>[</nowiki></code>. In many versions of DOS (MS-DOS/PC&nbsp;DOS 2.xx and higher, all versions of [[DR-DOS]] since 5.0, as well as [[PTS-DOS]], [[Embedded DOS]], [[FreeDOS]] and [[RxDOS]]) the switch character to be used is defined by a value returned from a system call ([[INT&nbsp;21h]]/AH=37h). The default character returned by this API is <code>/</code>, but can be changed to a hyphen-minus on the above-mentioned systems, except for Datalight ROM-DOS and MS-DOS/PC&nbsp;DOS 5.0 and higher, which always return <code>/</code> from this call (unless one of many available [[Terminate & Stay Resident|TSR]]s to reenable the SwitChar feature is loaded). In some of these systems (MS-DOS/PC&nbsp;DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 and higher, PTS-DOS, Embedded DOS, FreeDOS and RxDOS), the setting can not only be controlled by programs, but also pre-configured by a [[SWITCHAR (CONFIG.SYS directive)|SWITCHAR]] directive in [[CONFIG.SYS]]. Embedded DOS provides a SWITCH command for the same purpose, whereas [[4DOS]] allows the setting to be changed via <code>SETDOS /W:n</code>. Under DR-DOS, if the setting has been changed from <code>/</code>, the first directory separator <code>\</code> in the display of the [[PROMPT (DOS command)|PROMPT]] parameter <code>$G</code> will change to a forward slash <code>/</code> (which is also a valid directory separator in DOS, FlexOS, 4680 OS, 4690 OS, OS/2 and Windows) thereby serving as a visual clue to indicate the change. Some versions of DR-DOS [[COMMAND.COM]] also support a PROMPT token <code>$/</code> to display the current setting. COMMAND.COM since DR-DOS 7.02 and [[4DOS]] also provide a [[pseudo-environment variable]] named <code>[[%/%]]</code> to allow portable batchjobs to be written. Several external DR-DOS commands additionally support an [[environment variable]] <code>[[%SWITCHAR%]]</code> to override the system setting. However, many programs are hardwired to use <code>/</code> only, rather than retrieving the switch setting before parsing command line arguments.

[[Conversational Monitor System]] (CMS) uses a single [[Bracket#Parentheses .28 .29|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 sholuld be retained on the copy:
<code>COPY source file a target file b (REPLACE OLDDATE</code>

===Built-in usage help===
{{see also|help (command)}}
It is usual for a program to be able to display a brief summary of its parameters, typically when invoked with no arguments or one of <code>?</code>, <code>-?</code>, <code>-h</code>, <code>-H</code>, <code>/?</code>, <code>/h</code>, <code>/H</code>, <code>-help</code>, or <code>--help</code>.

Entering a program name without parameters in the hope that it will display parameters can be hazardous, as some programs and scripts execute without further ado.

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 <code>/</code> to <code>-</code>, programs may query the [[SwitChar]] API in order to determine the current setting. So, if a program is not hard-wired to support them all, a user may need to know the current setting even to be able to reliably request help.
If the SwitChar has been changed to <code>-</code> and therefore the <code>/</code> character is accepted as alternative path delimiter also at the DOS command line, programs may misinterpret options like <code>/h</code> or <code>/H</code> as paths rather than help parameters. However, if given as first or only parameter, most DOS programs will, by convention<!-- at least in all versions of DR-DOS as well as under 4DOS and NDOS -->, 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 <code>/H:1</code>, <code>/H:2</code>, 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 <code>/H:W</code> or in <code>/W:?</code> (assuming <code>/W</code> would be another parameter supported by the program)).

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 <code>-!</code>, <code>/!</code>, <code>-about</code>, or <code>--about</code>.

Since the <code>?</code> and <code>!</code> 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 "<code>[[HELP (command)|HELP]] ''command''</code>" command (or similar), which accepts a command name as calling parameter and will invoke an external help system.

In the DR-DOS family, typing <code>/?</code> or <code>/H</code> at the [[COMMAND.COM]] prompt instead of a command itself will display a dynamically generated list of available internal commands; [[4DOS]] and [[NDOS]] support the same feature by typing <code>?</code> at the prompt (which is also accepted by newer versions of DR-DOS COMMAND.COM); internal commands can be individually disabled or reenabled via <code>SETDOS /I</code>. In addition to this, some newer versions of DR-DOS COMMAND.COM also accept a <code>?%</code> command to display a list of available built-in [[DR-DOS system information variable|pseudo-environment variable]]s. Besides their purpose as quick help reference this can be used in batchjobs to query the facilities of the underlying command line processor.

===Command description syntax===
Built-in usage help and [[man page]]s commonly employ a small syntax to describe the valid command form:<ref>Conventions for describing commands on Unix-like operating systems:
    {{cite web
      | url = https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
      | title = The Open Group Base Specifications Issue 7
      | publisher = [[The Open Group]]
      | chapter = 12.1 Utility Argument Syntax
      | year = 2008
      | accessdate = 2013-04-07
    }}
    {{man|7|man-pages}}
</ref><ref>
    Conventions for describing commands on MS-DOS-like operating systems. Notable difference: The Windows Server 2003 R2 documentation uses italic letters for "Information that the user must supply", while the Server 2008 documentation uses angle brackets. Italics can not be displayed by the internal "help" command while there is no problem with angle brackets. 
    {{cite web
        | url = https://technet.microsoft.com/en-us/library/cc737438.aspx
        | title = Command shell overview
        | work = Windows Server 2003 Product Help
        | publisher = Microsoft
        | date = 2005-01-21
        | accessdate = 2013-04-07
    }}
    {{cite web
        | url = https://technet.microsoft.com/en-us/library/cc771080.aspx
        | title = Command-Line Syntax Key
        | work = Windows Server 2008 R2 TechNet Library
        | publisher = Microsoft
        | date = 2010-01-25
        | accessdate = 2013-04-07
    }}
</ref>

* angle brackets for ''required'' parameters: <code>ping <hostname></code>
* square brackets for ''optional'' parameters: <code>mkdir [-p] <dirname></code>
* ellipses for ''repeated'' items: <code>***** <source1> [source2...] <dest></code>
* vertical bars for ''choice'' of items: <code>netstat {-t|-u}</code>

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===
<!-- this is a file-system feature, nothing to do with the command line -->
In many areas of computing, but particularly in the command line, the [[space character]] can cause problems as it has two distinct and incompatible functions: as part of a command or parameter, or as a parameter or name [[Delimiter|separator]]. Ambiguity can be prevented either by prohibiting embedded spaces in file- and directory names in the first place (for example, by substituting them with [[underscores]] <code>_</code>), or by enclosing a name with embedded spaces between quote characters or using an [[escape character]] before the space, usually a [[backslash]] (<code>\</code>).  For example<br>
:<code>Long path/Long program name Parameter one Parameter two</code> ...
is ambiguous (is "program name" part of the program name, or two parameters?); however
:<code>Long_path/Long_program_name Parameter_one Parameter_two</code> ...,
:<code>LongPath/LongProgramName ParameterOne ParameterTwo</code> ...,
:<code>"Long path/Long program name" "Parameter one" "Parameter two"</code> ...
and<br>
:<code>Long\ path/Long\ program\ name Parameter\ one Parameter\ two</code> ...
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.

==Command-line interpreter==
{{see also|List of command-line interpreters}}

The terms '''command-line interpreter''', '''command line [[Shell (computing)|shell]]''', '''command language interpreter''', or identical abbreviation&nbsp;'''CLI''', are applied to [[computer program]]s designed to [[interpreter (computing)|interpret]] a sequence of lines of text which may be entered by a user, read from a [[computer file|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 [[programming language|language]] that is interpreted.

The unix [[Shebang (Unix)|<code>#!</code>]] and OS/2 EXTPROC commands facilitate the passing of batch files to external processors.  One can use this 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{{clarify|date=May 2012}} or in files like the registry or the [[OS/2]] <code>os2user.ini</code> file.

===Early history===
The earliest computers did not support interactive input/output devices, often relying on [[sense switch]]es and lights to communicate with the [[computer operator]].  This was adequate for [[Batch processing|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 [[Teletype Model 33]] ASR, but then on early [[Cathode ray tube|CRT]]-based [[computer terminals]] such as the [[VT52]].

All of these devices were purely text based, with no ability to display graphic or pictures.<ref>With the exception of [[ASCII art]]</ref> For business [[Application software|application programs]], text-based [[menu (computing)|menus]] were used, but for more general interaction the command line was the interface.

Around 1964 [[Louis Pouzin]] introduced the concept and the name ''shell'' in [[Multics]], building on earlier, simpler facilities in the [[Compatible Time-Sharing System]] (CTSS).<ref>{{cite web|last=Pouzin|first=Louis|title=The Origin of the Shell|work=Multicians.org|url=https://www.multicians.org/shell.html|accessdate=Sep 22, 2013}}</ref>{{better source|introduced the concept (sic)|date=September 2013}}
From the early 1970s the [[Unix]] operating system adapted the concept of a powerful command-line environment, and introduced the ability to ''[[Pipeline (Unix)|pipe]]'' the output of one command in as input to another. Unix also had the capability to save and re-run strings of commands as "[[shell scripts]]" which acted like custom commands.

The command-line was also the main interface for the early home computers such as the [[Commodore PET]], [[Apple II]] and [[BBC Micro]] – almost always in the form of a [[BASIC]] interpreter. When more powerful business oriented microcomputers arrived with [[*****/M]] and later [[MS-DOS]] computers such as the [[IBM PC]], the command-line began to borrow some of the syntax and features of the Unix shells such as [[globbing]] and [[Pipeline (Unix)|piping]] of output.

The command-line was first seriously challenged by the [[PARC (company)|PARC]] [[GUI]] approach used in the 1983 [[Apple Lisa]] and the 1984 [[Apple Macintosh]]. The majority of [[IBM PC]] users did not replace their [[command.com]] shell with a GUI until [[Windows 95]] was released in 1995{{citation needed |date= September 2014}}.

=== Modern usage as an operating system shell ===
While most computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:

* IBM OS/2 has the [[cmd.exe]] processor.  This copies the [[command.com]] commands, with extensions to [[REXX]].
* Windows users have a CLI environment named [[Windows Command Prompt]], which might use the [[CScript]] interface to alternate programs.  The new [[PowerShell]] program provides a command-line interface, but its applets are not written in shell-script. Implementations of the [[Unix shell]] are also available as part of the [[Microsoft POSIX subsystem|POSIX sub-system]],<ref>{{cite web|title=Windows POSIX shell compatibility|url=https://technet.microsoft.com/en-us/library/cc754351.aspx}}</ref> [[Cygwin]], and other software packages.
* [[FreeBSD]] uses csh as its default interactive shell.
* Apple Mac OS X<ref>via ''Finder, Applications, Utilities, [[Terminal (Mac OS X)|Terminal]]''</ref> and many [[Linux distribution]]s have the [[Bash (Unix shell)|Bash]] implementation of the [[Unix shell]]. Early versions of OS X used [[tcsh]] as the default shell.
* [[Embedded Linux]] (and other embedded [[Unix-like]]) devices often use the [[Almquist shell|Ash]] implementation of the Unix shell, as part of [[Busybox]].
* [[Android (operating system)|Android]] uses the [[Korn shell|mksh]] shell,<ref>[https://android.googlesource.com/platform/external/mksh/+/master android/platform/external/mksh/]</ref><ref>https://stackoverflow.com/questions/11950131/android-adb-shell-ash-or-ksh</ref> (a shell derived from [[Almquist shell|Ash]]<ref>{{cite web|title=Android sh source|url=https://github.com/android/platform_system_core/tree/master/sh}}</ref> in older versions<!-- Not clear if switch was in Gengerbread, or before-->) with commands from the separate ''toolbox''.<ref>{{cite web|title=Android toolbox source|url=https://github.com/android/platform_system_core/tree/master/toolbox}}</ref>
* Routers with [[Cisco IOS]],<ref>[https://www.cisco.com/en/US/docs/ios/12_0/configfun/configuration/guide/fcui.html#wp7687 ''"The Cisco IOS command-line interface (CLI) is the primary user interface..."'']</ref> [[Junos]]<ref>[https://www.juniper.net/techpubs/software/junos/junos55/swconfig55-getting-started/html/cli-overview-getting-started.html ''"...the software that you use whenever you access the router..."'']</ref> and many others are commonly configured from the command line.

==Scripting==
Most command-line interpreters support [[script (computer programming)|scripting]], to various extents. (They are, after all, interpreters of an interpreted [[programming language]], albeit in many cases the language is unique to the particular command-line interpreter.) They will interpret scripts (variously termed [[shell script]]s or [[batch file]]s) written in the [[programming language|language]] that they interpret. Some command-line interpreters also incorporate the interpreter engines of other languages, such as [[REXX]], in addition to their own, allowing the executing of scripts, in those languages, directly within the command-line interpreter itself.

Conversely, [[scripting programming language]]s, in particular those with an [[eval]] [[function (programming)|function]] (such as [[REXX]], [[Perl]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]] or [[Jython]]), can be used to implement command-line interpreters and filters. For a few [[operating system]]s, most notably [[DOS]], such a command interpreter provides a more flexible command line interface than the one supplied. In other cases, such a command interpreter can present a highly customised user interface employing the user interface and input/output facilities of the language.

==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.  Editors and data-bases 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.

There are a number of pre-mouse games, like [[Colossal Cave Adventure|Adventure]] or King's Quest 1-3, which relied on the user typing commands at the bottom of the screen.  One controls the character by typing commands like 'get ring' or 'look'.  The program returns a dialog which describes how the character sees it, or makes the action happen.  The [[text adventure]] [[The Hitchhiker's Guide to the Galaxy (video game)|The Hitchhiker's Guide to the Galaxy]], a piece of [[interactive fiction]] based on [[Douglas Adams|Douglas Adam's]] book of the same name, is a teletype-style command-line game.

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, [[Everything is a file|devices are files]] too, so the normal type of file for the shell used for stdin,stdout and stderr is a [[Teleprinter#Teleprinters in computing|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&nbsp;– console or graphical, which then usually process the command line without presenting a user-console.

Programs like the OS/2 [[E (editor)|E]] editor and some other IBM [[text editor|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" [[web app]]s, [[about:config|access browser configuration]], as well as perform a search. [[Google]], which has been called "the command line of the internet" will perform a domain-specific search when it detects search parameters in a known format.<ref>{{cite web|url=https://www.knaster.com/2004/04/google_strange_.html|title=Google strange goodness}}</ref> This funcionality is present whether the search is trigged from a browser field or one on Google's web site.

==Quotes==
{{quotation|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.|[[Brian Kernighan]] & [[Rob Pike]]<ref>Brian W. Kernighan and Rob Pike, "The UNIX Programming Environment", ''Prentice-Hall'' (1984).</ref>}}

==See also==
* [[Comparison of command shells]]
* [[List of command-line interpreters]]
* [[Orthodox file manager]], also known as command-based file manager{{dubious|invented terminology|date=September 2013}}

{{Div col begin}}

===Concepts===
* [[Batch processing]]
** [[Batch file]]
* [[Console application]]
* [[Interpreter directive]]
* [[Read-eval-print loop]]
* [[Shell (computing)]]
* [[Scripting language]]
** [[Shell script]]

===Uses===
* [[clig]]
* [[Computer terminal]]
** [[Terminal emulator]]
* [[Run command]]

===Misc===
* {{Section link|Graphical user interface|Comparison to other interfaces}}
* [[In the Beginning... Was the Command Line]]
* [[Natural user interface]]
{{Div col end}}

==References==
{{reflist}}

==External links==
*[https://www.patersontech.com/Dos/Softalk/Softalk.html The Roots of DOS] David Hunter, ''Softalk for the IBM Personal Computer'' March 1983. Archived at Patersontech.com since [https://web.archive.org/web/20001003150623/https://www.patersontech.com/Dos/Softalk/Softalk.html 2000].

{{Operating system}}

{{DEFAULTSORT:Command-Line Interface}}
[[Category:User interfaces]]
[[Category:User interface techniques]]
[[Category:Software architecture]]
[[Category:History of human–computer interaction]]
[[Category:Computing commands| ]]