http___en.wikipedia.org_wiki_Command-line_interface_1.xml
1.1 2.1 2.2 3.1 4.1 5.1 5.2 5.3 5.4
Интерфейс с команден ред Интерфейс с команден ред или текстов интерфейс (на английски: Command-line interface (CLI)) е механизъм за взаимодействие на операционната система или софтуера на компютър чрез въвеждане на команди за изпълняване на определена задача. При изцяло текстовите интерфейси, за разлика от графичните потребителски интерфейси, потребителите могат да работят със системата единствено чрез въвеждане на команди. При някои приложения като MATLAB и AutoCAD командният ред е интегриран заедно с графичния потребителски интерфейс. Приложение[редактиране | edit source] CLI интерфейси се използват често от програмисти и системни администратори, в инженерните и научни среди. Популярни са също сред хората със зрителни увреждания, тъй като командите както и получаваната обратно информация могат да се визуализират чрез използването на т.нар. брайлови дисплеи. Програма, която имплементира такъв текстов интерфейс често се нарича команден интерпретатор или шел (на английски: shell). Най-популярните примери са различните Unix shell (sh, ksh, csh, tcsh, bash и т.н.), историческата CP/M и COMMAND.COM на MS-DOS/IBM-DOS.
1.1 2.1 2.2 2.3 3.1 3.2 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 6.1 6.2 7.1 7.2 7.3 7.4 8.1 8.2 8.3 8.4 9.1 10.1 10.2 10.3 10.4 11.1 11.2 12.1 13.1 13.2 14.1 15.1 15.2 15.3 16.1 16.2 16.3 17.1 17.2 17.3 17.4 17.5 18.1 19.1 19.2 19.3 19.4 19.5 19.6 20.1 21.1 21.2 22.1 22.2 22.3 22.4 23.1 24.1 25.1 26.1 27.1 28.1 28.2 28.3 28.4 28.5 29.1 30.1 30.2 30.3 30.4 30.5 30.6 30.7 30.8 31.1 31.2 31.3 31.4 31.5 32.1 33.1 33.2 33.3 34.1 35.1 35.2 35.3 36.1 37.1 38.1 38.2 39.1 40.1 40.2 41.1 42.1 43.1 44.1 45.1 46.1 46.2 47.1 48.1 49.1 50.1 51.1 51.2 51.3 52.1 53.1 55.1 56.1 56.2 57.1 57.2 58.1 59.1 60.1 61.1 62.1 62.2 62.3 63.1 63.2 63.3 64.1 64.2 65.1 65.2 66.1 67.1 68.1 68.2 69.1 69.2 70.1 70.2 70.3 70.4 70.5 71.1 71.2 71.3 71.4 71.5 71.6 71.7 71.8 72.1 72.2 72.3 73.1 74.1 74.2 74.3 75.1 76.1 77.1 78.1 79.1 80.1 81.1 82.1 82.2 82.3 83.1 84.1 84.2 85.1 85.2 86.1 86.2 87.1 88.1 89.1 90.1 91.1 91.2 92.1 92.2 93.1 94.1 95.1 95.2 96.1 96.2 96.3 97.1 98.1 99.1 100.1 101.1 102.1 102.2 102.3 102.4 103.1 103.2 103.3 104.1 105.1 105.2 105.3 105.4 105.5 105.6 106.1 106.2 106.3 107.1 107.2 107.3 107.4 108.1 108.2 108.3 108.4 109.1 109.2 109.3 110.1 111.1 111.2 112.1 113.1 114.1 114.2 115.1 116.1 117.1 118.1 119.1 120.1 121.1 122.1 123.1 124.1 124.2 125.1 126.1 127.1 128.1 129.1 130.1 131.1 132.1 133.1 133.2 134.1 135.1 136.1 136.2 137.1 138.1 138.2 139.1 139.2 140.1 141.1 142.1 143.1 144.1 144.2 145.1 145.2
Command-line interface A command-line interface (CLI) is an interface or dialog between the user and a program, or between two programs, where a line of text (a command line) is passed between the two. Many graphical interfaces, such as the OS/2 Presentation Manager and the various Windows shell use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shell or in files like the registry or the OS/2 os2user.ini file. Command-line interfaces replaced point-and-load menus (Basic, MS-DOS Executive in Windows 2.x) and externally loaded programs (such as punched cards and game cartridges), when computers became sufficiently powerful to handle parsing of user input, and keep several programs in a runnable condition. This happened at the conversion to 16-bit computers, although text-menus continued to be supplied with computers well after this time. The command-line interface derives from the teletype or teletypewriter machines. These were originally connected to remote machines of the same kind, which allowed an early text conversations between remote users. The conversations appeared on the output paper as the messages were sent by the user (by pressing the 'enter' key). One could feed pre-loaded messages through an attached paper tape reader. Teletype machines were connected to the early computers. Users then had teletype conversations with computers. The commands were sent by the user and the computer, the conversation recorded on the paper. Eventually, the paper was replaced by a text screen with scrolling lines, and eventually one where the computer could address the position on the screen. The teletype lives on in Unix-like OSs in Terminal emulator form.[1] The invention of the standard input/output interface (stdin, stdout, etc) allowed command line output to be redirected to input for another program to look at. Various console hacks allowed one to store and edit commands in software, as well as use 'character-based graphics', which presented the user with a dialog, rather than a line interface. The alternative to the command at the line is a graphical dialog. Command-line options become buttons and switches presented on the dialog, while sending the dialog or command does much the same thing. DBase allowed one to build command lines from dialogs and further editing the command on its line. Take Command allows one to launch a dialog in stead of options on the command line. The Command Line Interface continues to co-evolve with GUIs like those provided by Microsoft Windows, Mac OS and the X Window System. Programs that make use of external helper programs, often make use of command lines embedded in the GUI interface or configuration. In some applications, such as MATLAB, AutoCAD or EAGLE, a CLI is integrated with the GUI, with some benefits of both. Commands exist to open directory windows, read and write to the clipboard and do other graphical things directly from batch files or the command line. [edit] Usage A CLI is used whenever a large vocabulary of commands or queries, coupled with a wide (or arbitrary) range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with operating system command shells. CLIs are also used by systems with insufficient resources to support a graphical user interface. Some computer language systems (such as Python, Forth, LISP and many dialects of BASIC) provide an interactive command-line mode to allow for experimentation. 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 displays. A program that implements such a text interface is often called a command-line interpreter, command processor or shell, whereby 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—for example, the default Windows GUI is created by a shell program named EXPLORER.EXE, as defined in the SHELL=EXPLORER.EXE line in the WIN.INI configuration file. Examples of command-line interpreters include the various Unix shells (sh, ksh, csh, tcsh, bash, etc.), the historical CP/M CCP, and 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 DEC's RSX and RSTS CLIs. Under most operating systems, it is possible to replace the default shell program by more specialized or powerful alternatives; some widespread examples include 4DOS for DOS, 4OS2 for OS/2, and 4NT or Take Command for Windows. There are command-line interpreters for editing text files like ED and EDLIN, DEBUG, for disk management DISKPART, DFSEE, calculators (PC-DOS ACALC), all of which present a usable command prompt. In November 2006, Microsoft released version 1.0 of Windows PowerShell (formerly codenamed Monad), which combined features of traditional Unix shells with their object-oriented .NET Framework. MinGW and Cygwin are open-source packages for Windows that offer a Unix-like CLI. Microsoft provides MKS Inc.'s ksh implementation MKS Korn shell for Windows through their Services for UNIX add-on. The latest versions of the Macintosh operating system are based on a variation of Unix called Darwin. On these computers, users can access a Unix-like command-line interface called Terminal found in the Applications Utilities folder. (This terminal uses bash by default.) Some applications provide both a CLI and a GUI. In some cases, the GUI is a wrapper around a CLI application; other times, there is a CLI to control a GUI application. The engineering/scientific numerical computation package MATLAB provides no GUI for some calculations, but the CLI can handle any calculation. The three-dimensional-modelling program Rhinoceros 3D provides a CLI as well as a distinct scripting language. In some computing environments, such as the Oberon or Smalltalk user interface, most of the text which appears on the screen may be used for giving commands. [edit] Anatomy of a shell CLI A CLI can generally be considered as consisting of syntax and semantics. The syntax is the grammar that all commands must follow. In the case of operating systems (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 defaults that can be changed to customize the results. Useful command lines can be saved by assigning a character string or alias to represent the full command, or several commands can be grouped to perform a more complex sequence — for instance, compile the program, install it, and run it — 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   outputFile - doSomething how | doSomething how | do Something 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 '>' in the third example is a redirection operator, telling the command-line interpreter to send the output of the command not to the screen but to the file named on the right of the '>'. This will overwrite the file. Using '>>' will redirect the output and append it to the file. Another redirection operator is the vertical bar ('|'), which creates a pipeline where the output of one command becomes the input to the next command. [edit] CLI and resource protection In some CLIs, the commands issued are not coupled to any conceptual place within a command hierarchy. A user can specify relative or absolute paths to any command or data. Examples of this include DOS, OS/2, Windows, and UNIX, which provide forms of a change directory command which allows access to any directory in the system. In some systems, protection of resources is provided by a system of resource ownership by privileged groups, and password-protected user accounts which are members of specific groups. MS-DOS/PC-DOS provides no such resource protection, nor do versions of Windows prior to the Windows NT family. (Both of these were designed as single-user systems, where it was assumed that the owner would simply not allow people that she/he did not fully trust to have physical access to the computer at all. UNIX, by contrast, originated as a time-sharing system in corporate and university environments. Similarly, Concurrent CP/M, Concurrent DOS, Multiuser DOS, REAL/32 and the members of the DR-DOS family offer various user- as well as file/directory-oriented protection schemes as well.) Other CLIs (such as those in network routers) limit the set of commands that a user can perform to a subset, determined by location within a command hierarchy, grouped by association with security, system, interface, etc. The location within this hierarchy and the options available are often referred to as a mode. In these systems the user might traverse through a series of sub-hierarchies, each with their own subset of commands. For example, if the CLI had two modes called interface and system, the user would enter the word 'interface' at the command prompt and then enter an interface mode, where a certain subset of commands and data are available. At this point system commands are not accessible and would not be accessible until the user explicitly exits the interface mode and enters the system mode. [edit] Command prompt 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 prompt the user to take action. A prompt usually ends with one of the characters $, %, #, :, > and often includes other information, such as the path of the current working directory. On many Unix system and derivative systems, it is common for the prompt to end in a $ or % character if the user is a normal user, but in a # 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 prompt command or by directly changing the value of the corresponding %PROMPT% environment variable. The default of most modern systems, the C:\> style is obtained, for instance, with " prompt $P$G". The default of older DOS systems, C> is obtained by just " prompt", although on some systems this produces the newer C:\> style, unless used on floppy drives A: or B:; on those systems " prompt $N$G" can be used to override the automatic default and explicitly switch to the older style. On many Unix systems, the $PS1 variable can be used, although other variables also may have an impact on the prompt (depending on what shell is being used). In the bash shell, a prompt of the form [time] user@host: work_dir $ could 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. It is used to display information on the same line as the prompt, but right justified. In RISC OS, the command prompt is a ' *' symbol, and thus (OS)CLI commands are often referred to as "star commands".[2] 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 ' [edit] Arguments A command-line argument or parameter is an argument sent to a program being called. In principle a program can take many command-line arguments, the meaning and importance of which depend entirely upon 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: rm file.s "file.s" is a command-line argument which tells the program rm to remove the file "file.s". 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 main function. [edit] Command-line option 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 files inside a directory. By default—that is, when the user simply types directory—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. Sometimes different programs use different syntax in the same operating system. For example: - Options may be indicated by -, /, 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 : or =. Thus "Prog -fFilename", "Prog -f Filename", "Prog -f:Filename", "Prog -f=Filename". - Some programs allow single-character options to be combined; others do not. The switch "-fA" may mean the same as "-f -A", 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. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software. In DOS, OS/2 and Windows the forward slash ('/') is more prevalent, although the hyphen–minus is also sometimes used there. FlexOS, 4680 OS and 4690 OS use '-'. In many versions of DOS (MS-DOS/PC-DOS 2.xx and higher, all versions of DR-DOS since 5.0, as well as in PTS-DOS and FreeDOS) the current switch character to be used is defined by a value returned from a system call (INT 21/AH=37h). The default character returned by this API is '/', but can be changed to a hyphen-minus on all above-mentioned systems (except for MS-DOS/PC-DOS 5.0 and higher). In some of these systems (MS-DOS/PC-DOS 2.xx/3.xx, DR-DOS 7.02 and higher, and FreeDOS), the setting can not only be controlled by programs, but also pre-configured by a SWITCHAR directive in CONFIG.SYS. While applications should retrieve this setting before parsing command line arguments, many existing programs don't adhere to this standard and are hardwired to use '/' only. Under DR-DOS, if the setting has been changed from '/', the first directory separator '\' in the display of the PROMPT parameter $G will change to a forward slash '/' (also a valid directory separator in DOS, FlexOS, 4680 OS, 4690 OS, OS/2 and Windows) as a visual clue to indicate the change. Some command-line interpreters (including newer versions of DR-DOS COMMAND.COM and 4DOS) also provide pseudo-environment variables named %/% or %SWITCHAR% to allow portable batchjobs to be written. It is impossible to know what arguments a program can recognise, and what syntax to use without consulting program documentation. It is usual for a program to display a brief summary of its parameters when invoked with a command-line which is typically one of: no parameters; ?; -?; -h; /?; /h; -help; or --help. 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. [edit] 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, if supported by the command-line interpreter and the programs taking these parameters as arguments, by enclosing a name with embedded spaces between quote characters or using a 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-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. [edit] Command-line interpreter The terms command-line interpreter, command line shell, command language interpreter, or identical abbreviation CLI, are applied to computer programs designed to interpret a sequence of lines of text which may be entered by a user, read from a file or another kind of data stream. The context of interpretation is usually one of a given operating system or programming language. Command-line interpreters allow users to issue various commands in a very efficient (and often terse) way. This requires the user to know the names of the commands and their parameters, and the syntax of the language that is interpreted. The unix /# 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. [edit] Early history 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 CRT-based computer terminals such as the VT52. All of these devices were purely text based, with no ability to display graphic or pictures.[3] For business application programs, text-based menus were used, but for more general interaction the command line was the interface. From the early 1970s the Unix operating system on minicomputers pioneered the concept of a powerful command-line environment, which Unix called the "shell", with the ability to "pipe" the output of one command in as input to another, and 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 CP/M and later MSDOS 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. The majority of IBM PC users did not replace their command.com shell with a GUI until Windows 95 was released in 1995. [edit] 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. - MS Windows users have the cmd.exe environment, 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 POSIX sub-system[4], Cygwin, and other software packages. - Apple Mac OS X[5] and GNU/Linux have the Bash implementation of the Unix shell. - Embedded Linux (and other embedded Unix-like) devices often use the Ash implementation of the Unix shell, as part of Busybox. - Android uses a Unix shell derived from Ash[6] with commands from the separate toolbox[7]. - Routers with Cisco IOS[8], Junos[9] and many others are commonly configured from the command line. [edit] Scripting Most command-line interpreters support 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 scripts or batch files) written in the 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 languages, in particular those with an eval function (such as REXX, Perl, Python, Ruby or Jython), can be used to implement command-line interpreters and filters. For a few operating systems, 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. [edit] 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 games from the pre-mouse games, (like Kings 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 game 'h2g2' (hitchhiker's guide to the galaxy, based on Douglas Adam's book of the same name), is a teletype-style command-line game. The most notable of these interfaces is the STDIO interface, which allows the output of one command to be passed to the input of another. Text files can serve either purpose as well. This provides the interfaces of piping, filters and redirection. Under Unix, devices are files too, so the normal type of file for the shell used for stdin,stdout and stderr is a tty device file. Another command-line interface allows a shell program to launch helper programs, either to launch documents or start a program. The command is porcessed internally by the shell, and then passed on to another program to launch the document. The graphical interface of Windows and OS/2 rely heavily on command-lines passed through to other programs - console or graphical, which then usually process the command line without presenting a user-console. Programs like the OS/2 'E' editor and some other IBM editors, can process command-lines normally meant for the shell, the output being placed directly in the document window. One should remember that the 'address line' in a web browser is in fact a command line, even to the thing about about:blank interface. One can program extra commands for a web browser, say to open the registry at a given item, by using the reg: keyword. On the other hand, features like command history and editing are not nesseccarily part of the command-line interface. [edit] Quotes 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. [edit] See also - Batch processing - Batch file - clig for tcl/c - Comparison of computer shells - Console application - Text terminal - Graphical user interface#Comparison to other interfaces - Interpreter directive - In the Beginning... Was the Command Line - Natural user interface - Read-eval-print loop - Run command in Microsoft Windows - Scripting language - Shell (computing) - Shell script - Terminal emulator [edit] References - ^ "The TTY demystified". http://www.linusakesson.net/programming/tty/index.php. - ^ RISC OS 3 User Guide, Part 3: Outside the desktop (page 125) Published by Acorn Computers Limited, ISBN 1-85250-124-2, Edition 2 Part number 0496,075 Issue 1 March 1992 - ^ With the exception of ASCII art - ^ "Windows POSIX shell compatibility". http://technet.microsoft.com/en-us/library/cc754351.aspx. - ^ via Finder, Applications, Utilities, Terminal - ^ "Android sh source". https://github.com/android/platform_system_core/tree/master/sh. - ^ "Android toolbox source". https://github.com/android/platform_system_core/tree/master/toolbox. - ^ "The Cisco IOS command-line interface (CLI) is the primary user interface..." - ^ "...the software that you use whenever you access the router..." - ^ Brian W. Kernighan and Rob Pike, "The UNIX Programming Environment", Prentice-Hall (1984). [edit] External links - In the Beginning... Was the Command Line — Short book about CLIs by Neal Stephenson. - The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.