Command-line interpreter




Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command. Because it must satisfy both the interactive and programming aspects of command execution, it is a strange language, shaped as much by history as by design.

— Brian W. Kernighan & Rob Pike

The term command-line interpreter (CLI) is applied to computer programs designed to interpret a sequence of lines of text which may be entered by a user, read from a file or another kind of data stream. The context of interpretation is usually one of a given operating system or programming language.

Command-line interpreters allow users to issue various commands in a very efficient (and often terse) way. This requires the user to know the names of the commands and their parameters, and the syntax of the language that is interpreted.

The Unix #! mechanism and OS/2 EXTPROC command facilitate the passing of batch files to external processors. One can use these mechanisms to write specific command processors for dedicated uses, and process external data files which reside in batch files.

Many graphical interfaces, such as the OS/2 Presentation Manager and early versions of Microsoft Windows use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shellclarification needed or in files like the registry or the OS/2 OS2USER.INI file.

Early historyedit

The earliest computers did not support interactive input/output devices, often relying on sense switches and lights to communicate with the computer operator. This was adequate for batch systems that ran one program at a time, often with the programmer acting as operator. This also had the advantage of low overhead, since lights and switches could be tested and set with one machine instruction. Later a single system console was added to allow the operator to communicate with the system.

From the 1960s onwards, user interaction with computers was primarily by means of command-line interfaces, initially on machines like the 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.nb 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 introduced the ability to pipe the output of one command in as input to another. Unix also had the capability to save and re-run strings of commands as "shell scripts" which acted like custom commands.

The command-line was also the main interface for the early home computers such as the Commodore PET, Apple II and BBC Micro – almost always in the form of a BASIC interpreter. When more powerful business oriented microcomputers arrived with 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 shelledit

While most non-expert computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:

  • The default VAX/VMS command shell, using the DCL language, has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite. Unix command shells have been ported to VMS and DOS/Windows 95 and Windows NT types of operating systems. COMMAND.COM and Windows NT cmd.exe have been ported to Windows CE and presumably works on Microsoft Windows NT Embedded 4.0
  • Windows Resource Kit and Windows Services for Unix include Korn and the Bourne shells along with a Perl interpreter (Services of Unix contains Active State ActivePerl in later versions and Interix for versions 1 and 2 and a shell compiled by Microsoft)
  • 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.
  • cmd.exe and COMMAND.COM are part of the Windows NT stream of operating systems.
  • 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.
  • Windows users have a CLI environment named Windows Command Prompt, which might use the CScript interface to alternate programs. PowerShell 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, 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, psh
  • COMMAND.COM (4DOS), Windows NT cmd.exe (4NT, TCC), and OS/2 cmd.exe (4OS2) and others based on them are enhanced shells which can be a replacement for the native shell or a means of enhancement of the default shell.
  • 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.
  • FreeBSD uses tcsh as its default interactive shell for the superuser, and ash as default scripting shell.
  • Apple macOSnb and many Linux distributions have the Bash implementation of the Unix shell. Early versions of macOS used tcsh as the default shell.
  • Embedded Linux (and other embedded Unix-like) devices often use the Ash implementation of the Unix shell, 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.
  • Routers with Cisco IOS, Junos and many others are commonly configured from the command line.

Comments

Popular posts from this blog

History

25) Republic Day 2021: Parade the right time security arrangements traffic prohibitions to Delhi Metro providers - All you need to know

Types