Command-line interface

Operating system command-line interfaces

Operating system (OS) command-line interfaces are usually distinct programs supplied with an OS. 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 the following:

• Nushell
• DEC's DIGITAL Command Language (DCL) in OpenVMS and RSX-11
• Unix shells, including sh, ksh, csh, tcsh, zsh, and Bash
• CP/M's CCP
• DOS' COMMAND.COM, as well as the OS/2 and Windows cmd.exe programs, the latter groups based heavily on DEC's RSX-11 and RSTS CLIs^{[citation needed]}

Under most operating systems, the default shell program can be replaced with alternatives; examples include 4DOS for DOS, 4OS2 for OS/2, and 4NT / Take Command for Windows.

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 (UI; command-line interface, GUI, etc.) or a programming interface—to a command interpreter and processor, as well as to the broad capabilities of the operating system. For example, the default Windows GUI is a shell GUI named explorer.exe, as defined on the SHELL=EXPLORER.EXE line in the WIN.INI configuration file. This program, strictly speaking, is a shell GUI and, by extension, a shell; to be precise, the Windows shell is the shell32.dll library, and explorer.exe is a shell GUI for shell32.dll. However, explorer.exe is neither a command-line interpreter nor a shell CLI.

Application command-line interfaces

Application programs (as opposed to operating systems) may also have command-line interfaces.

An application program may support none, some, or all of the following three major types of CLI mechanisms:

• Parameters: Most command-line interfaces support a way 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 of entering commands.
• Inter-process communication: Most operating systems support mechanisms for it (for example, standard streams or named pipes). Command lines from client processes may be redirected to a CLI program by one of these mechanisms.

Some applications support a CLI, presenting their own prompt to a 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 computer program for numerical analysis, are available via the CLI, whereas the MATLAB GUI exposes only a subset.

In the video game Colossal Cave Adventure from 1976, the player uses a CLI to enter one or two words in order to explore a cave system.

CLI and resource protection

On some systems, such as Unix-like systems or Windows, a user can change the set of available commands by modifying which paths appear in the PATH environment variable or its equivalent. On Unix-like systems, the file containing the executable or script for a command also must be given execute permission. The directories in the PATH variable are searched in the order that they are listed. By reordering the path, a user can run, for example, the executable \OS2\MDOS\E.EXE instead of \OS2\E.EXE, when the default order is the opposite. Renaming executables also works: users often rename their favorite text editor to EDIT, for example.

A command line allows a person to restrict the available commands, for example, by blocking access to advanced internal commands. The Bourne shell and workalikes (software with similar functionality) such as Bash can be run as a restricted shell. Among other effects, this restriction prohibits the user from modifying the PATH environment variable, so that if PATH is set to include only directories that contain only permitted commands, a user can run only those commands. The Windows executable cmd.exe also supports restricting available commands. Often, shareware programs limit the range of commands, potentially displaying a message at the command-line prompt, such as "Your administrator has disabled running batch files".^{[clarification needed]}

Some CLIs, such as those in network routers, have a hierarchy of modes, with a different set of commands supported in each mode. Each set of commands is grouped by association with security, system, interface, and so on. In these systems, a user might traverse a series of submodes. For example, if the CLI has two modes called interface and system, the user might use the command interface to enter the interface mode. After entering this mode, commands from the system mode may be unavailable until the user exits the interface mode and enters the system mode.

In IBM's MVS operating systems, the Authorized Program Facility (APF) allows certain authorized programs to run with enhanced privileges, analogous to the superuser account UID(0) in Unix-like systems. As another example, a set of extensions to IBM's Time Sharing Option environment (TSO/E) supports calling authorized commands, but only those commands, programs and services in an installation-controlled list.

Command prompt

A command prompt (or prompt) is a sequence of (one or more) characters used in a command-line interface to indicate readiness to accept commands. It literally promptss the user to take action. A prompt usually ends with one of the characters $, %, #, :, >, or -, and it often includes other information, such as the path of the current working directory and the hostname.

On many Unix and derivative systems, a prompt commonly ends in a $ or % character if the user is a normal user, but a # character if the user is a superuser (root in Unix terminology).

End users can often modify prompts. Depending on the environment, these prompts may include colors, special characters, and other elements. Such elements may be variables and functions for the current time, user, shell number, or working directory. These modifications have several goals—for example, 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 prompt's definition 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 Windows NT's cmd.exe, users can modify the prompt by issuing a PROMPT command or by directly changing the value of the corresponding %PROMPT% environment variable. The default prompt of most modern systems, the C:\> style, is obtained, for instance, by using PROMPT $P$G. The default prompt of older DOS systems, C>, is obtained through just PROMPT, although on some systems this command produces the newer C:\> style, unless used on floppy drives A: or B:. On those systems, PROMPT $N$G can 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 may also affect the prompt (depending on the shell used). In the Bash shell, a prompt of the form

[time] user@host: work_dir $

can be set by issuing the command

export PS1='[\t] \u@\H: \W $'

In zsh, the $RPROMPT 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. This feature is used to display information on the same line as the real prompt, but the information is right-justified.

In RISC OS, the command prompt is a * character; thus, (OS) CLI commands are often referred to as star commands. A user can also access the same commands from other command lines (such as the BBC BASIC command line) by preceding a command with a * character.

In IBM's TSO environment, the command prompt is referred to as the READY prompt, after the word READY in the prompt.

Some shells, such as Bash, zsh, and PowerShell, allow the use of prompt systems that display much more information in the command prompt; such information may include the type of remote connection, the state of machine sensors, or additional information about a version control system. These shells often use several ANSI colors, Unicode characters, and advanced shell features to create a colorful display.

Example of prompt system displays

All the information that can be displayed by the Liquid Prompt command prompt system, here using its Jolly theme

A Liquid Prompt display example, using its default theme

A Liquid Prompt display example, using its Pureship theme

A Liquid Prompt display example, using its Powerline theme

Arguments

This article needs more citations. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Command-line interface" – news · newspapers · books · scholar · JSTOR (June 2026) (Learn how and when to remove this message)

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, a command-line argument might look like this:

rm file.s

file.s is a command-line argument that tells the program rm to remove the file named file.s.

Some programming languages—such as C, C++, and Java—allow a program to interpret the command-line arguments by handling them as string parameters in the program's main function. Other languages, such as Python, expose an OS-specific application programming interface (API; connection between computers or programs) through the language's sys module, in particular the sys.argv list of command-line arguments.

In Unix-like operating systems, a single - character used in place of a file name is a special value that specifies that a program should handle data coming from the standard input or send data to the standard output.

Command-line options

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 characters such as commas or spaces. Separators are not always required, as in the command lines dir/? and dir /? in DOS, which have the same effect of listing the dir command's available options; by contrast, the command line dir --help (in many versions of Unix) does actually require the option to be preceded by at least one space (and the option is case-sensitive).

The format of options varies widely between operating systems. In most cases, the syntax is by convention rather than being an OS requirement. The entire command line is simply a string passed to a program, which can process this string however the programmer would like, provided that the interpreter can determine where the command name ends and the command's arguments and options begin.

A few representative samples of command-line options, most related to listing files in a directory, illustrate some conventions:

Samples of command-line options

Operating system	Command	Valid alternative	Notes
OpenVMS	directory/owner	Dir /Owner	Instructs the directory command to also display the ownership of the files. Note: the directory command name is not case-sensitive, and it can be abbreviated to as few letters as required to remain unique.
Windows	DIR/Q/O:S d*	dir /q d* /o:s	Displays ownership of files whose names begin with d (or D), sorted by size, smallest first. Note: spaces around the argument d* are required.
Unix-like systems	ls -lS D*	ls -S -l D*	Displays in long format files and directories whose names begin 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/e/s 04-26-80/b	List /S/E 4-26-80/B	Lists 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.
VM/CMS CLI	LISTFILE (FULLDATE)	l(ful	Includes the date the file was last written in the list. Note: the LISTFILE command name is not case-sensitive, and it can be abbreviated to as few letters as required to remain unique.
OS/360 operator commands	START TAPERDR,DSNAME=FOO.BAR	S TAPERDR,DSN=FOO.BAR	Starts the procedure named TAPERDR with the supplied data set name.
TSO	LISTCAT LEVEL(FOO) MEMBERS	LISTC L(FOO) M	Lists datasets at the specified index level and lists members for each PDS.
	SEND 'text' USER(FOO)	SE 'text' U(FOO)	Sends a message to the specified user.

Command-line argument parsing is used to analyze the arguments of a program, and such functionality is available in various languages. For example, the getopt() function for parsing arguments is available in the C POSIX library.

Abbreviating commands

See also: Tab completion

In the Multics operating system, 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 as -lgsj. In Multics, commands are often abbreviated as well, typically as the initial letters of words that are connected by underscores to form command names; an example is using the abbreviation did for the command delete_iacl_dir.

In some other systems, abbreviations are automatic, such as accepting enough of the first characters of a command name to identify it uniquely (e.g., SU to abbreviate SUPERUSER). Still other systems may have certain abbreviations preprogrammed (e.g., MD to abbreviate MKDIR in COMMAND.COM) or user-defined via batch scripts and aliases (e.g., alias md mkdir in tcsh, which makes md an abbreviation for mkdir).

Option conventions in DOS, Windows, OS/2

In DOS, OS/2, and Windows, different programs called from their COMMAND.COM or cmd.exe command-line interpreters (as well as the interpreters' internal commands) may use different syntax within the same operating system. For example:

• Options may be indicated by the switch characters / or -, depending on the program; some programs accept both characters.
• Options may or may not be case-sensitive.
• Sometimes options and their arguments are run together, and sometimes they are separated by whitespace or a character, typically : or =. Examples include the commands Prog -fFilename, Prog -f Filename, Prog -f:Filename, and Prog -f=Filename.
• Some programs allow single-character options to be combined, but other programs do not. The switch -fA may have the same meaning as -f -A, be incorrect, or be a valid but different parameter.

In DOS, OS/2, and Windows, the forward slash (/) is most prevalent for options, although the hyphen-minus is sometimes used. In many versions of DOS (MS-DOS/PC DOS 2.xx and higher; all versions of DR-DOS since 5.0; and PTS-DOS, Embedded DOS, FreeDOS, and RxDOS) the switch character (sometimes abbreviated switchar or switchchar) to be used is defined by a value returned from a system call (software interrupt INT 21h/AX=3700h). The default character returned by this API is the / character, but the default can be changed to a hyphen-minus on these systems, except under Datalight ROM-DOS and MS-DOS/PC DOS 5.0 and higher; these operating systems always return the / character from this call. An exception is when one of many available terminate-and-stay-resident programs (TSRs) that re-enable the SwitChar feature is loaded. In some of these systems (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 and higher, PTS-DOS, Embedded DOS, FreeDOS, and RxDOS), the switch setting can also be preconfigured by a SWITCHAR directive in the CONFIG.SYS file. General Software's Embedded DOS provides a SWITCH command for the same purpose, whereas 4DOS allows the setting to be changed via the command SETDOS /W:n. Under DR-DOS, if the switch setting has been changed from the / character, the first directory separator \ in the display of the PROMPT parameter $G changes to a forward slash / character, thereby serving as a visual cue to indicate the change. (This forward slash is also a valid directory separator in DOS, FlexOS, 4680 OS, 4690 OS, OS/2, and Windows.) In addition, the current switch setting is reflected in built-in help screens. Some versions of DR-DOS's COMMAND.COM also support a PROMPT token $/ to display the current setting. COMMAND.COM since DR-DOS 7.02 also provides a pseudo-environment variable named %/% that allows portable batch jobs to be written. Several external DR-DOS commands additionally support an environment variable %SWITCHAR% to override the system setting.

However, many programs are hardwired to use only the / character, rather than retrieving the switch setting before parsing command-line arguments. A few programs, mainly ports from Unix-like systems, are programmed to accept the - character even if the switch character is not set to it. (For example, the programs netstat and ping, supplied with Microsoft Windows, accept the /? option to list available options, and yet the list specifies the - convention.)

Option conventions in Unix-like systems

This section needs more citations. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (July 2021) (Learn how and when to remove this message)

In Unix-like systems, an ASCII hyphen-minus character begins options; the new convention, also used by the GNU software collection, is to use two hyphens followed by a word (e.g., --create) to identify the option's use. By contrast, the old convention (still available for frequently used options) is to use one hyphen followed by one letter (e.g., -c). If one hyphen is followed by two or more letters, this may signify that multiple options are being specified, or it may signify that the second and subsequent letters form a parameter (such as filename or date) for the first option.

Two hyphen-minus characters with no letters (--) may indicate that the remaining arguments should not be treated as options; this is useful, for example, if a file name itself begins with a hyphen, or if additional arguments are meant for an inner command (e.g., when using the sudo command). Double hyphen-minuses are also sometimes used to prefix long options, where more descriptive option names are used. This feature is common in GNU software. The getopt function and program, as well as the getopts command, are usually used for parsing command-line options.

Unix command names, arguments, and options are case-sensitive (except in a few cases, primarily when popular commands from other operating systems have been ported to Unix).

Option conventions in other systems

FlexOS, 4680 OS, and 4690 OS use the - character, and CP/M typically used the [ character.

The Conversational Monitor System (CMS) uses a single left parenthesis to separate options at the end of a 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 in the copy: COPY source file a target file b (REPLACE OLDDATE)

Operator commands in OS/360 use a comma-separated list of positional and keyword parameters; only the documented command and keyword abbreviations are valid. Keyword values are separated from keywords by equal signs.

TSO commands use a space-separated list of positional and keyword parameters; keywords may be truncated to any unique substring. Only the documented command abbreviations are valid. Keyword values are placed inside parentheses.

Data General's CLI under its RDOS, AOS, and other operating systems—as well as the version of the CLI that came with the company's Business Basic—uses only the / character as the switch, is case-insensitive, and allows local switches on some arguments to control the way they are interpreted. For example, in the command MAC/U LIB/S A B C $LPT/L, the global option U for the macro assembler command appends user symbols, and there are two local switches: one specifying that LIB should be skipped on pass 2, and the other directing the 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 ?, -?, -h, -H, /?, /h, /H, /Help, -help, or --help.

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 / to -, programs may query the SwitChar API in order to determine the current setting. So, if a program is not hardwired 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 - and therefore the / character is accepted as an alternative path delimiter at the DOS command line, programs might misinterpret options such as /h or /H as paths rather than help parameters. However, if given as the first or only parameter, most DOS programs will, by convention, accept it as a 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 giving a verbosity level as an optional argument to the help parameter (as in /H:1, /H:2, etc.) or they give just a short help on help parameters with a 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:? [assuming that /W 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 such as -!, /!, -about, or --about.

Since the ? and ! 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 a calling parameter and will invoke an external help system.

In the DR-DOS family, typing /? or /H 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 ? at the prompt (which is also accepted by newer versions of DR-DOS COMMAND.COM); internal commands can be individually disabled or re-enabled via SETDOS /I. In addition to this, some newer versions of DR-DOS COMMAND.COM also accept a ?% command to display a list of available built-in pseudo-environment variables. Besides their purpose as quick help reference, this can be used in batch jobs to query the facilities of the underlying command-line processor.

Command description syntax

Built-in usage help and man pages commonly employ a small syntax to describe the valid command form:

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

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 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 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 _), 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" …

and

Long\ path/Long\ program\ name Parameter\ one Parameter\ two …

are not ambiguous. Unix-like operating systems minimize the use of embedded spaces to minimize the need for quotes. In Microsoft Windows, a user often has to use quotes because embedded spaces (such as in directory names) are common.

Early history

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 such as the Teletype Model 33 ASR, but then on early CRT-based computer terminals such as the VT52.

All of these devices were purely text-based, with no ability to display graphics or pictures. For business application programs, text-based 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).^{[better source needed]}

From the early 1970s, the Unix operating system adapted the concept of a powerful command-line environment, and it introduced the ability to pipe the output of one command as input to another. Unix also had the capability to save and re-run strings of commands as shell scripts that 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 CP/M and later 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 piping of output.

The command line was first seriously challenged by the PARC GUI approach used in the 1983 Apple Lisa and the 1984 Apple Macintosh. A few computer users used GUIs such as GEOS and Windows 3.1, but the majority of IBM PC users did not replace their COMMAND.COM shell with a GUI until Windows 95 was released in 1995.

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:

• Unix-like systems—include the Bourne shell and compatible shells, such as Bash and other Unix shells.
  • FreeBSD uses tcsh as its default interactive shell for the superuser, and ash as the default scripting shell.
  • Many Linux distributions have Bash.
  • Apple macOS and some Linux distributions use zsh. Previously, macOS used tcsh and Bash.
  • Embedded Linux (and other embedded Unix-like) systems often use ash, as part of BusyBox.
  • 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.
• OpenVMS—uses the DIGITAL Command Language (DCL).
  • Unix command shells have been ported to OpenVMS.
• DOS and Windows—have several command-line environments
  • COMMAND.COM is the command-line interpreter of MS-DOS, IBM PC DOS, and Windows 9x, as well as clones such as DR-DOS, SISNE plus, PTS-DOS, ROM-DOS, and FreeDOS.
  • Windows NT has cmd.exe, and later versions have PowerShell
  • The 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)
  • Windows users might use the CScript interface to run alternative programs from the command line. Implementations of the Unix shell are also available as part of the POSIX subsystem, Cygwin, MKS Toolkit, UWIN, Hamilton C shell, and other software packages. Available shells for these interoperability tools include csh, ksh, sh, Bash, rsh, tclsh, and less commonly zsh and psh
  • DCL has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite.
  • Yet another cmd.exe is a stripped-down shell for Windows CE 3.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.
• IBM OS/2 (and derivatives such as eComStation and ArcaOS)—has the cmd.exe processor. This copies the COMMAND.COM commands, with extensions to Rexx.
• Implementations of PHP—have a shell for interactive use called php-cli.
• Standard Tcl/Tk—has 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.
• HarmonyOS, OpenHarmony, and Oniro—use the commands from the third-party toolbox compatibility system attached to the Linux kernel of the kernel abstraction layer (KAL) subsystem and the POSIX (musl-libc) library with the Linux application binary interface (ABI) of the HongMeng kernel alongside the default Shell with its own native exec commands.
• Routers with Cisco IOS, Junos, and 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.