PROMPT (command)

Adapted from the English Wikipedia article PROMPT (command), available under CC BY-SA 4.0Updated 9 August 2025

A command-line interface (CLI), occasionally referred to as a command-line shell, is a method of interacting with software by entering commands in text form. Emerging in the mid-1960s on computer terminals, CLIs provided a dynamic alternative to earlier, non-interactive methods such as punched cards.

For almost thirty years, the CLI was the primary mode of software interaction; nowadays, graphical user interfaces (GUIs) have become more common. Nevertheless, numerous operating systems and development tools continue to depend on CLIs because of their speed and efficiency.

By allowing commands to be saved and run as scripts, CLIs support automation and streamline repetitive processes. This capability is enabled through command-line interpreters or processors, which handle the execution of entered commands.

Other interface options include GUIs (like the Windows desktop environment), text-driven menu systems (such as DOS Shell or IBM AIX SMIT), and keyboard shortcut schemes.

Comparison to graphical user interfaces

In contrast to GUIs, CLIs demand fewer system resources and provide faster access to commands for seasoned users. They facilitate automation through features like line editing, command history recall, and scripting languages that accept variables and parameters. The ability to review or rerun previous commands enhances user productivity.

Although CLIs typically depend on documentation or built-in help functions for user guidance, they lack graphical enhancements such as diverse font styles or expanded editing areas found in GUIs. For newcomers, CLIs may appear less intuitive compared to icon-based or menu-driven interfaces without consulting reference materials.

Operating system command-line interfaces

Operating system command-line interfaces are specialized programs included with the OS, commonly known as command-line interpreters, command processors, or shells.

Examples encompass Nushell; DEC's DIGITAL Command Language (DCL) used in OpenVMS and RSX-11; various Unix shells including the sh, ksh, csh, tcsh, zsh, and Bash; as well as CP/M's CCP, DOS's COMMAND.COM, and the OS/2 and Windows CMD.EXE shells—these latter ones largely derive from DEC's RSX-11 and RSTS command-line environments. Most operating systems permit users to substitute the default shell with alternatives like 4DOS for DOS, 4OS2 for OS/2, or 4NT / Take Command on Windows.

While the term shell often denotes a command-line interpreter, its precise meaning refers to any program that provides an interface—whether command-line based, graphical, or programming-oriented—between the user and the OS's command interpreter. For example, Windows' default graphical shell is EXPLORER.EXE, specified in WIN.INI; this represents a GUI shell rather than a CLI. The fundamental Windows shell is actually shell32.dll, with explorer.exe serving as its graphical front-end.

Application command-line interfaces

Command-line interfaces may also be integrated into application software.

Applications might implement one or more of these CLI methods:

Parameters: Supplying data at startup.
Interactive command-line sessions: Accepting user commands after launch.
Inter-process communication: Utilizing OS mechanisms like standard streams or named pipes for directing commands.

Some programs offer their own CLI prompts; others provide both CLI and GUI options. In certain situations, the GUI acts as a wrapper around a CLI executable; alternatively, the CLI may serve as an optional interface. The feature sets between CLI and GUI versions can vary—for instance, all capabilities of MATLAB are accessible through its CLI, whereas its GUI presents only a portion of these functions.

A notable early example is the 1975 game Colossal Cave Adventure, which employed a CLI to interact with users via simple text inputs.

History

The command-line interface originated from communication methods involving teleprinter (TTY) devices, frequently utilizing telex systems for sending orders or receiving confirmations. Early computers depended on teleprinters as the primary means for operators to interact with the system.

Mechanical teleprinters were succeeded by "glass tty" units—comprising keyboards and screens that simulated teleprinter functionality. The introduction of "smart" terminals brought enhancements such as full-screen cursor control and the ability to edit data locally. With the advent of the microcomputer revolution, physical hardware terminals were largely replaced by terminal emulator programs running on personal computers, facilitating connections to mini- or mainframe systems or enabling PC-to-PC communication, often through Bulletin Board System software.

In early operating systems, command-line interfaces were embedded within resident monitor programs and could not be easily swapped out. The first shell that could be replaced was introduced in the Multics time-sharing operating system. In 1964, Louis Pouzin at MIT developed the tool called RUNCOM, which supported command scripts with argument substitution, and he coined the term shell, framing commands as a programming language concept. Subsequently, Glenda Schroeder created the initial Multics shell.

The earliest Unix shell, known as the Thompson shell, was developed by Ken Thompson in 1971 at Bell Labs, drawing inspiration from Schroeder’s Multics shell. The 1977 release of the Bourne shell superseded it, functioning both as an interactive interpreter and a scripting language with structured programming constructs. This shell laid the groundwork for successors such as the KornShell (ksh), Almquist shell (ash), and the popular Bourne-again shell (Bash).

During the early days of microcomputers, command-line interfaces like CP/M, DOS, and AppleSoft BASIC were standard. Throughout the 1980s and 1990s, graphical user interfaces became dominant with platforms like the Apple Macintosh and Microsoft Windows, yet command lines remained indispensable for tasks handled by system administrators, programmers, and batch processing operations.

In November 2006, Microsoft released version 1.0 of Windows PowerShell, which merged Unix shell capabilities with their object-oriented .NET Framework. Open-source tools such as MinGW and Cygwin offer Unix-style command-line environments on Windows systems. Additionally, Microsoft provides the MKS Korn shell through their Services for UNIX package.

Since 2001, macOS has been built upon the Unix-like foundation of Darwin. Users access its command-line interface via the Terminal emulator or remotely through SSH connections. The default shell in macOS is now the Z shell, although Bash, tcsh, and the KornShell remain available; prior to macOS Catalina, Bash was set as the default.

Usage

Command-line interfaces are often favored when a broad set of commands or queries with numerous options can be entered more swiftly as text than through graphical user interfaces. This is particularly true for operating system shells. CLIs also serve environments where resources are insufficient to support graphical interfaces. Several programming languages—including Python, Forth, LISP, Rexx, and multiple dialects of BASIC]—provide interactive command-line modes for quick code execution.

CLIs are extensively utilized by developers, system administrators, engineers, scientists, and experienced computer users. They are also preferred by individuals with visual impairments since commands and outputs can be accessed using devices like refreshable Braille displays.

Structure of a shell CLI

The typical format of a command line is as follows:

prompt command param1 param2 param3 … paramN

prompt — signals that the system is ready to receive input, often displaying contextual details and concluding with a visual indicator.
command — the instruction typed by the user; it can be:
- Internal commands executed directly by the interpreter (built-in functions).
- External commands that invoke executable programs found through system path lookup.
param1 … paramN — arguments or options whose structure varies depending on the command.

These components are usually separated by spaces and ended with a newline character. While this pattern is common, it is not universally applied.

A command-line interface comprises two main aspects: syntax, which defines the command structure, and semantics, which governs the permissible operations on data and how these are expressed through syntax. Different operating systems such as DOS and Unix establish their own syntax conventions, while embedded system manufacturers (including Nortel, Juniper Networks, Cisco Systems) implement proprietary standards. When syntax and semantics align closely, users can operate multiple CLIs or reuse scripts across environments with minimal adaptation.

Basic CLI functionality includes presenting a prompt, receiving a command line input terminated by Enter, executing the command, and then displaying output or error messages. More sophisticated CLIs perform additional tasks like parameter validation, interpretation, expansion, and output redirection.

Unlike graphical user interfaces where actions are triggered by buttons or menus, command lines explicitly declare user intentions and often incorporate customizable default settings. Users can save individual commands or sequences as aliases or scripts to automate complex procedures—such as compiling code, installing software, or running applications—thereby improving productivity by reducing repetitive manual input.

Typical command-line patterns include:

doSomething how toFiles
doSomething how sourceFile destinationFile
doSomething how < inputFile > outputFile
doSomething how | doSomething how | doSomething how > outputFile

In these examples, doSomething functions as the action verb, how serves as an adverb specifying execution style (for instance, verbose or silent), and toFiles indicates target objects, usually files. The > operator redirects output to overwrite a file; >> appends output instead. The pipe symbol (|) links commands so that one’s output becomes the next’s input.

CLI and resource protection

On platforms such as Unix-like systems or Windows, control over which commands are accessible is managed by adjusting the PATH environment variable. In Unix-like environments, executable files must also have proper permissions set to be runnable. The system searches directories in the order specified in PATH, allowing certain executables to be prioritized by rearranging or renaming them.

Command-line interfaces may impose restrictions on available commands to limit user capabilities. For example, shells like the Bourne shell and related shells such as Bash can operate in a restricted shell mode that prevents changes to PATH and confines command execution to approved directories only. Similarly, Windows’ CMD.EXE supports mechanisms for limiting commands. Some shareware applications restrict command usage entirely and may display notices like "your administrator has disabled running batch files."

Certain CLIs—especially those used in network router environments—employ hierarchical modes with distinct sets of commands assigned to each mode (such as interface versus system). Users switch between these modes to access appropriate commands, thereby enhancing both security and operational management.

Command prompt

A command prompt indicates that a command-line interface is ready to receive input. It often concludes with symbols such as $, %, #, :, or >, and commonly displays contextual details like the current working directory or hostname.

On numerous Unix platforms, normal user prompts typically finish with $ or %, whereas superusers (root) see a prompt ending with #. Users have the ability to personalize their prompts by incorporating colors, variables, or custom functions to improve clarity and differentiate between sessions.

In DOS's COMMAND.COM and Windows NT's cmd.exe, the prompt is adjusted using the PROMPT command or by setting the %PROMPT% environment variable. For instance, the familiar C:\> prompt is created by executing PROMPT $P$G. Legacy DOS prompt styles such as C> can be selected by assigning specific values to PROMPT.

Unix shell prompts are determined through variables like $PS1. In Bash, a prompt that displays the time, username, hostname, and current directory can be configured as follows: <syntaxhighlight lang="bash">export PS1='[\t] \u@\H: \W $'</syntaxhighlight>

Within zsh, the variable $RPROMPT manages an optional right-aligned prompt that provides extra information without shifting the input cursor’s position.

In RISC OS, the prompt character is a *, which leads to CLI commands being termed star commands. These commands can also be invoked from other command lines by prefixing them with *.

Arguments

A command-line argument or parameter refers to data supplied to a program upon execution. Programs often accept multiple arguments that specify input/output files or alter program functionality.

Generally, a program is launched by typing its name followed by one or more arguments. For example, on Unix systems:

Here, serves as an argument instructing the rm utility to delete the specified file.

Programming languages such as C, C++, and Java handle command-line arguments as string parameters passed into their respective main functions. Other languages like Python access these arguments through operating system interfaces such as sys.argv.

Within Unix-like operating system environments, using a single hyphen as a filename signals that data should be read from standard input or sent to standard output.

Command-line option

A command-line option—also known as a flag or switch—is used to modify how a command operates. These options follow the command name and are generally separated by spaces. For instance, DOS commands like Dir/? and DIR /? display help information about available options, whereas Unix commands such as dir --help require a space before specifying options.

The format of options varies significantly depending on the operating system and tends to follow conventions rather than strict rules. The entire command line is passed to the program as a string for parsing.

The following table illustrates examples of file-listing options across different systems:

Operating system	Command	Valid alternative	Notes
OpenVMS	`directory/owner`	`Dir /Owner`	Shows file ownership. Commands are case-insensitive and support abbreviation.
Windows	`DIR/Q/O:S d*`	`dir /q d* /o:s`	Displays ownership of files starting with d, sorted ascending by size. Spaces around argument d* are necessary.
Unix-like systems	`ls -lS D*`	`ls -S -l D*`	Lists files beginning with D in long format, sorted descending by size. Spaces are required; options may be combined (e.g., -lS).
Data General RDOS CLI	`list/e/s 04-26-80/b`	`List /S/E 4-26-80/B`	Lists attributes for files dated before April 26, 1980. /B modifies only the date argument; /S and /E apply globally.
VM/CMS CLI	`LISTFILE (FULLDATE)`	`l(ful`	Includes last modification date. Commands are case-insensitive and abbreviatable.

Abbreviating commands

Within Multics, it is possible to shorten command-line options and subsystem keywords, a practice influenced by the PL/I programming language, which features abbreviated keywords (such as STRG for STRINGRANGE). For example, the Multics forum subsystem permits the abbreviation of the -long_subject parameter to -lgsj. Frequently, Multics commands employ abbreviations derived from the initial letters of each word connected by underscores, like did representing delete_iacl_dir.

Other operating systems may enable automatic abbreviation by accepting just enough leading characters to uniquely identify a command (for instance, SU as shorthand for SUPERUSER). Alternatively, predefined abbreviations might be used (such as MD for MKDIR in COMMAND.COM), or users can define their own aliases (e.g., alias md mkdir in tcsh).

Option conventions in DOS, Windows, OS/2

Programs running on DOS, OS/2, and Windows platforms via COMMAND.COM or CMD.EXE exhibit diverse option syntax styles within the same environment, including:

Different option prefix characters: /, -, or both.
Variability in case sensitivity.
Options and their arguments may be concatenated or separated by whitespace or delimiters like : or =.
Some utilities permit combining single-letter switches; others require them to be separate.

In these systems, the forward slash (/) is predominantly used as the switch character, although the hyphen-minus is occasionally employed. Various DOS versions—such as MS-DOS/PC DOS 2.xx+, DR-DOS 5.0+, PTS-DOS, Embedded DOS, FreeDOS, and RxDOS—allow configuring the switch character through a system call (INT 21h/AX=3700h). The default is /, but it can be changed to hyphen-minus except in Datalight ROM-DOS and MS-DOS/PC DOS 5.0+ where it remains fixed at /. Some environments support pre-setting this via a SWITCHAR directive inside CONFIG.SYS. For instance, Embedded DOS includes a SWITCH command; 4DOS uses SETDOS /W:n. Under DR-DOS, modifying this setting also changes how directory separators appear in command prompts for visual feedback and updates built-in help documentation accordingly. Additionally, DR-DOS COMMAND.COM supports special tokens and environment variables like $/ and %/% to enhance batch file compatibility. Certain external DR-DOS utilities respect an environment variable named %SWITCHAR%, which can override the system default.

Nonetheless, numerous applications are hardcoded to utilize /, disregarding any switch character configuration. A few utilities ported from Unix-like environments accept the hyphen-minus (-) regardless of system settings—for example, Windows-supplied tools like netstat and ping. These programs tend to support both conventions but document their options using the hyphen-minus style.

Option conventions in Unix-like systems

In Unix-like operating systems, options are introduced with the ASCII hyphen-minus. The contemporary GNU standard employs two hyphens followed by a descriptive word (e.g., --create), whereas the traditional style uses a single hyphen followed by a single letter (e.g., -c). When multiple letters follow one hyphen, this can denote either several combined options or an option accompanied by parameters.

A pair of hyphens alone (--) commonly indicates that all following arguments should not be interpreted as options—this is particularly useful for filenames beginning with a hyphen or when invoking nested commands such as sudo. Long options prefixed with double hyphens are prevalent in GNU software suites. Standard utilities for parsing these options include the getopt function and the getopts shell command.

Unix commands along with their options are case-sensitive except in certain ports adapted from other operating systems.

Option notation in alternative systems

In systems such as FlexOS, 4680 OS, and 4690 OS, the dash (-) serves as the standard option indicator.

The CP/M environment traditionally employed the left square bracket ([) for this purpose.

With the Conversational Monitor System (CMS), options are appended using a single opening parenthesis placed at the conclusion of commands; for instance, COPY source file a target file b (REPLACE OLDDATE).

The command-line interface of Data General on RDOS, AOS, and Business Basic exclusively utilizes the slash (/) as the switch prefix. This system is case-insensitive and allows for local switches on certain parameters to influence their behavior. An example is MAC/U LIB/S A B C $LPT/L, where both global and local switches modify commands such as the macro assembler.

Integrated help functionality

Many CLI applications lack explicit visual indicators for supported operations. To compensate, they often present a usage summary when launched without arguments or when invoked with common help triggers like -h, --help, or variants such as /h. However, if parameters are optional, running a program without arguments might initiate execution unintentionally.

Not all applications accommodate every option prefix character. Within DOS environments, the default switch character may alternate between / and -, which programs can detect through the SwitChar API. Conflicts can arise if option characters coincide with path delimiters—for example, /h could be interpreted as part of a file path rather than a help request. Nevertheless, most DOS utilities accept help flags as either the first or only argument regardless of SwitChar configuration.

Certain programs provide multiple tiers of help detail using parameters like /H:1, distinguishing between brief and comprehensive help displays. Additional context-sensitive assistance might be accessed by combining help flags with specific options (e.g., /H:W).

Occasionally, software includes "about" information—such as version details, authorship, or licensing—accessible via options like -about or --about. Since characters like ? and ! often fulfill other command-line roles, they are generally avoided as sole triggers for help content.

When built-in guidance is inadequate, many operating systems provide external help commands that accept a command name argument to launch dedicated assistance modules.

In DR-DOS, entering /? or /H at the COMMAND.COM prompt dynamically lists internal commands. Similarly, 4DOS and NDOS implement this feature through the ? command. Utilities such as SETDOS /I enable toggling of internal commands. Later DR-DOS versions also recognize ?%, which enumerates internal pseudo-environment variables for quick reference or batch processing queries.

Syntax conventions for command descriptions

Concise notation is commonly employed in built-in usage messages and man pages to outline valid command syntax:

Angle brackets denote mandatory arguments: ping <hostname>
Square brackets indicate optional arguments: mkdir [-p] <dirname>
Ellipses represent multiple occurrences: cp <source1> [source2…] <dest>
Vertical bars signify alternatives: netstat {-t|-u}

These symbols differ from their usual shell interpretations. Angle brackets may sometimes be omitted when parameter names are clearly distinct from literal values.

The space character

Within command-line environments, the space character serves dual roles: it can be part of a command or argument, as well as act as a delimiter, which often leads to confusion. To address this, spaces are typically avoided in filenames or directory names by using substitutes like underscores _, or by enclosing such names in quotation marks or preceding spaces with escape characters like the backslash (\). For instance:

Long path/Long program name Parameter one Parameter two

is unclear, whereas

Long_path/Long_program_name Parameter_one Parameter_two,

"Long path/Long program name" "Parameter one" "Parameter two", and

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

are all clearly interpreted. Unix-style systems generally reduce embedded spaces to limit the necessity for quoting, while Microsoft Windows commonly requires quotations due to frequent spaces in folder names.

Command-line interpreter

A command-line interpreter is software that processes text input from users, files, or other streams within the framework of an operating system or programming language.

These interpreters facilitate streamlined execution of commands but demand familiarity with command syntax, parameter usage, and the interpreter’s language rules.

Techniques such as Unix’s #! and OS/2’s EXTPROC enable batch scripts to call external processors, supporting customized command processors and specialized data file management.

Graphical user interfaces like OS/2’s Presentation Manager and early versions of Microsoft Windows utilize command lines to initiate auxiliary programs for opening files and applications. These commands are maintained within the graphical shell environment or configuration settings such as the registry or OS/2’s OS2USER.INI file.

Early history

Initial computing systems lacked interactive input/output hardware, depending instead on sense switches and indicator lights for operator communication, which suited batch processing running single programs. Subsequently, system consoles were introduced to provide rudimentary operator interaction.

Starting in the 1960s, user interaction evolved towards command-line interfaces accessible via devices like the Teletype Model 33 ASR and CRT terminals such as the VT52. These text-based terminals supported business functions through command lines or text menus.

In 1964, Louis Pouzin developed the concept of a shell in the Multics operating system, building upon earlier innovations such as the Compatible Time-Sharing System (CTSS). During the early 1970s, Unix advanced this concept by incorporating robust command-line environments featuring piping and scripting capabilities for automation.

Early personal computers (for example, Commodore PET, Apple II, BBC Micro) predominantly operated using BASIC interpreters accessed via command lines. Business-oriented microcomputers running CP/M and later DOS (such as the IBM PC) adopted Unix-like functionalities including globbing and piping.

The prevalence of command lines diminished with the advent of graphical user interfaces pioneered by PARC, particularly seen in the 1983 Apple Lisa and 1984 Apple Macintosh. Although some users embraced GUIs like GEOS and Windows 3.1, widespread adoption among IBM PC users occurred primarily after the release of Windows 95 in 1995.

Contemporary role as an operating system shell

Although graphical user interfaces are prevalent among everyday users, expert users frequently rely on robust command-line environments available across multiple platforms:

The default shell on VAX/VMS employs the DCL, which has been adapted for Windows through utilities such as PC-DCL.
COMMAND.COM acts as the command interpreter for MS-DOS, IBM PC DOS, and compatible systems like DR-DOS and FreeDOS.
The Windows Resource Kit and Services for UNIX provide Korn and Bourne shells alongside Perl interpreters; later editions incorporate ActiveState’s ActivePerl.
IBM OS/2 variants, including eComStation and ArcaOS, utilize cmd.exe, an enhanced version of COMMAND.COM with added support for REXX scripting.
The Windows NT line uses cmd.exe, while Windows CE features a more streamlined variant.
PocketDOS delivers an MS-DOS-style interpreter on Windows CE, maintaining compatibility with legacy utilities such as QBasic.
On Windows platforms, users can access environments like CScript and PowerShell; Unix shells are accessible via POSIX subsystems or third-party tools like Cygwin, MKS Toolkit, UWIN, and Hamilton C shell, supporting shells such as csh, ksh, sh, Bash, rsh, tclsh, and zsh.
Interactive command-line environments exist for languages including PHP (php-cli), Tcl/Tk (Tclsh/Wish), Python, Ruby, Lua, and XLNT.
FreeBSD sets tcsh as the default for administrative users and ash for scripting purposes; numerous Linux distributions adopt Bash as their standard shell.
Apple’s macOS and select Linux distributions have transitioned to zsh as the default shell; earlier macOS versions used tcsh or Bash.
Embedded Linux systems commonly utilize ash through Busybox implementations.
Android replaced its earlier ash-derived shell with mksh, complemented by toolbox commands.
HarmonyOS and OpenHarmony incorporate external toolbox commands alongside their native shells.
Network devices running Cisco IOS or Junos predominantly rely on command-line interfaces for configuration tasks.
The Plan 9 operating system employs the rc shell, which shares similarities with the Bourne shell.

Scripting

Most command interpreters provide varying levels of support for scripting, processing scripts—often referred to as shell scripts or batch files—written in their respective languages. Additionally, some shells embed interpreters for other languages such as REXX, enabling direct script execution within the command-line environment.

Conversely, scripting languages equipped with an eval function—examples include REXX, Perl, Python, Ruby, and Jython—can be utilized to develop command-line interpreters and filters. In certain operating systems like DOS, these interpreters offer more adaptable interfaces than the native shell, allowing users to craft highly tailored experiences by leveraging the language’s input/output features.

Alternative command-line interfaces

The command line acts as a communication medium between software and users, serving as a substitute for dialog boxes. Applications such as text editors and database systems often present command lines where alternative processors might operate. Some solutions integrate command lines with dialog boxes to facilitate command construction, exemplified by DBase and recent versions of 'Take Command'.

Programs including BASIC, diskpart, Edlin, and QBASIC offer command-line interfaces that sometimes utilize the system shell. Even calculators may function through either command-line or dialog-based interfaces.

Emacs provides a command-line interface via its minibuffer, enabling text editing for commands and parameters with results displayed in separate buffers.

Several text-mode games like Adventure and King's Quest 1-3 rely on typed inputs for player interaction. The interactive fiction title The Hitchhiker's Guide to the Galaxy exemplifies this teletype-style command-driven gameplay.

A fundamental model is that of standard streams, which allows output from one program to be piped into another using filters and redirection. In Unix-like systems, devices are treated as files; shell standard input/output/error streams correspond to device files such as ttys.

Certain shells initiate helper utilities to open files or launch applications by internally processing commands before handing them off. Graphical environments in Windows and OS/2 heavily depend on such command lines managed by console or GUI programs without relying on user consoles.

Editors like OS/2’s E editor can interpret shell-style commands directly within document windows.

Web browsers’ address bars function similarly to command lines by launching web apps, accessing configuration pages (about:config), or executing searches. Google is often described as the "internet’s command line," performing domain-specific queries directly from browser input fields or its homepage.

JavaScript libraries facilitate development of browser-based command line applications either as standalone web apps or integrated components of larger platforms. Examples include CLI interfaces to DuckDuckGo. Web-based SSH clients also enable browser access to server-side command-line environments.

Many PC video games incorporate developer consoles—command line interfaces used for debugging purposes, modding content, cheating mechanisms, or bypassing game sections.

External links

The Origins of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Preserved on Patersontech.com since 2000.
Windows Commands: Microsoft TechNet Database "Command-Line Reference"