Shell (computing): Difference between revisions
this seems too broad |
m Reverted edits by 2409:4063:6E4F:DD6F:D537:BC96:4EE2:B7E7 (talk): editing tests (HG) (3.4.13) |
||
(203 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Computer program that exposes an operating system's services to a human user or other programs}} |
|||
[[File:X-Window-System.png|thumb|upright=1.35|A graphical interface from the |
[[File:X-Window-System.png|thumb|upright=1.35|A graphical interface similar to one from the late 1980s, which features a [[text-based user interface|TUI]] window for a [[man page]], a shaped window (oclock) as well as several [[Icon (computing)|iconified]] windows. In the lower right we can see a [[terminal emulator]] running a [[Unix shell]], in which the user can type commands as if they were sitting at a [[Computer terminal|terminal]].]] |
||
In [[computing]], a '''shell''' is a |
In [[computing]], a '''shell''' is a computer program that exposes an [[operating system]]'s services to a human user or other programs. In general, operating system shells use either a [[command-line interface]] (CLI) or [[graphical user interface]] (GUI), depending on a computer's role and particular operation. It is named a shell because it is the outermost layer around the operating system.<ref name="Economist">{{citation|title=The Internet's fifth man|magazine=[[The Economist]]|department=Brain scan|publisher=[[Economist Group]]|location=London|date=December 13, 2013|url=https://www.economist.com/news/technology-quarterly/21590765-louis-pouzin-helped-create-internet-now-he-campaigning-ensure-its|quote=Mr Pouzin created a program called RUNCOM that helped users automate tedious and repetitive commands. That program, which he described as a “shell” around the computer’s whirring innards, gave inspiration—and a name—to an entire class of software tools, called command-line shells, that still lurk below the surface of modern operating systems.}}</ref><ref name="JargonFile"> |
||
{{cite web|url=http://www.catb.org/jargon/html/S/shell.html|title=shell|work=The Jargon File|editor-first=Eric S. |editor-last=Raymond}} |
|||
</ref> |
|||
⚫ | |||
The design of a shell is guided by [[cognitive ergonomics]] and the goal is to achieve the best [[workflow]] possible for the intended tasks; the design can be constricted by the available computing power (for example, of the [[Graphics processing unit|GPU]]) or the available amount of graphics memory. The design of a shell is also dictated by the employed [[Peripheral|computer periphery]], such as [[computer keyboard]], [[pointing device]] (a mouse with one button, or one with five buttons, or a [[3D mouse]]) or [[touchscreen]], which is the direct [[human–machine interface]]. |
|||
⚫ | |||
⚫ | Most operating system shells are not ''direct'' interfaces to the underlying [[Kernel (operating system)|kernel]], even if a shell communicates with the user via [[peripheral device]]s attached to the computer directly. Shells are actually special applications that use the kernel [[API]] in just the same way as it is used by other application programs. A shell manages the user–system interaction by prompting users for input, interpreting their input, and then handling output from the underlying operating system (much like a [[read–eval–print loop| read–eval–print loop, REPL]]).<ref>{{cite web | url=http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.baseadmn%2Fdoc%2Fbaseadmndita%2Fshells.htm | title=Operating system shells | publisher=[[IBM]] Corp | work=AIX 6.1 Information Center | access-date=September 16, 2012}}</ref> Since the operating system shell is actually an application, it may easily be replaced with another similar application, for most operating systems. |
||
CLI shells allow some operations to be performed faster in some situations, especially when a proper GUI has not been or cannot be created. However, they require{{dubious}} the user to memorize commands and their calling syntax, and also to learn the shell-specific scripting language, for example [[bash script]]. CLIs are also easier to be operated via [[refreshable braille display]] and provide certain advantages to [[screen reader]]s. |
|||
⚫ | In addition to shells running on local systems, there are different ways to make remote systems available to local users; such approaches are usually referred to as remote access or remote administration. Initially available on [[multi-user]] [[mainframe computer|mainframes]], which provided text-based UIs for each active user ''simultaneously'' by means of a [[text terminal]] connected to the mainframe via serial line or [[modem]], remote access has extended to [[Unix-like]] systems and Microsoft Windows. On Unix-like systems, [[Secure Shell|Secure Shell protocol (SSH)]] is usually used for text-based shells, while [[SSH tunneling]] can be used for [[X Window System]]–based graphical user interfaces (GUIs). On Microsoft Windows, Remote Desktop Protocol can be used to provide GUI remote access, and since [[Windows Vista]], [[PowerShell|PowerShell Remote]] can be used for text-based remote access via WMI, RPC, and WS-Management.<ref>{{cite web |last1=Wheeler |first1=Sean |title=Running Remote Commands |url=https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=powershell-6 |website=Microsoft Docs |publisher=Microsoft |access-date=30 June 2019 |date=14 October 2018 |quote="You can run commands on one or hundreds of computers with a single PowerShell command. Windows PowerShell supports remote computing by using various technologies, including WMI, RPC, and WS-Management."}}</ref> |
||
Graphical shells have a low burden to start using a computer, and they are characterized as being simple and easy to use. With the widespread adoption of programs with GUIs, the use of graphical shells has gained greater adoption. Since graphical shells come with certain disadvantages (for example, lack of support for easy automation of operation sequences), most GUI-enabled operating systems also provide additional CLI shells. |
|||
⚫ | Most operating system shells fall into one of two categories{{snd}} command-line and graphical. Command-line shells provide a command-line interface (CLI) to the operating system, while graphical shells provide a graphical user interface (GUI). Other possibilities, although not so common, include a voice user interface and various implementations of a text-based user interface (TUI) that are not CLI, such as text-based menu systems. The relative merits of CLI- and GUI-based shells are often debated. Many computer users use both depending on the task to be performed. |
||
⚫ | |||
[[File:Linux kernel and gaming input-output latency.svg|thumb|upright=1.7|A particular view on the interaction between the [[end user]], hardware and software]] |
|||
==History== |
|||
⚫ | |||
Early interactive systems provided a simple command-line interpreter as part of the [[resident monitor]]. This interpreter might be called by different names, such as <code>COMCON</code> on DEC [[TOPS-10]] systems.<ref>{{cite book |last1=Digital Equipment Corporation |title=TOPS-10 MONITOR INTERNALS |date=Nov 1980 |pages=CMND-1–CMND-16 |url=http://bitsavers.org/pdf/dec/pdp10/TOPS10_monitorInternalsCourse/EY-CD150-HO-006_monInternal.pdf |access-date=Mar 29, 2022}}</ref> The interpreter would execute one of a number of predefined commands, one of which would be to run a user program. Common commands would log the user on and off the system, allocate, free, and manipulate devices and files, and query various pieces of information about the system or a user process.<ref>{{cite book |last1=Digital Equipment Corporation |title=DECSystem 10 Operating System Commands Manual |date=Aug 1977 |url=http://bitsavers.org/pdf/dec/pdp10/TOPS10/AA-0916C-TB_DEC10_Operating_Systems_Command_Manual_Ver_6_03_Aug77.pdf |access-date=Mar 29, 2022}}</ref> |
|||
{{quote box |
|||
⚫ | Most operating system shells are not ''direct'' interfaces to the underlying kernel, even if a shell communicates with the user via [[peripheral device]]s attached to the computer directly. Shells are actually special applications that use the kernel [[ |
||
|text=The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, ''as if it were called from the inside of another program''. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". |
|||
|author=Louis Pouzin |
|||
|title= |
|||
|source=The SHELL: A Global Tool for Calling and Chaining Procedures in the System <ref>{{cite web|last1=Poizin |first1=Louis|title=The SHELL: A Global Tool for Calling and Chaining Procedures in the System|url=https://people.csail.mit.edu/saltzer/Multics/Multics-Documents/MDN/MDN-4.pdf}}</ref> |
|||
|width = 50% |
|||
|align = right |
|||
}} |
|||
In 1964, for the [[Multics]] operating system, [[Louis Pouzin]] conceived the idea of "using commands somehow like a programming language," and coined the term ''shell'' to describe it.<ref>{{cite web |last1=Pouzin |first1=Louis |title=The Origin of the Shell |url=https://multicians.org/shell.html |website=multicians.org |access-date=Mar 29, 2022}}</ref> In a 1965 document, the shell is defined as "a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control. This procedure acts as an interface between console messages and subroutine [in the supervisor]."<ref>{{cite web |last1=Pouzin |first1=Louis |title=The SHELL: A Global Tool for Calling and Chaining Procedures in the System |url=https://people.csail.mit.edu/saltzer/Multics/Multics-Documents/MDN/MDN-4.pdf |website=MIT.edi |access-date=Mar 29, 2022}}</ref> This system was first implemented by [[Glenda Schroeder]] and an unnamed man from [[General Electric]].<ref>{{cite web |last1=Pouzin |first1=Louis |title=The Origin of the Shell |url=https://multicians.org/shell.html |website=multicians.org |access-date=Feb 12, 2024}}</ref> |
|||
Multics also introduced the ''active function'', a key concept in all later shells. This is defined as {{blockquote|a string... which is replaced by a character string return value before the command line containing it is executed. Active functions are often used... to implement command-language macros.<ref>{{cite book |last1=Honeywell, inc. |title=Multics Common Commands |date=Feb 1983 |pages=1-1–1-2 |url=http://bitsavers.org/pdf/honeywell/multics/GB58-0_commonCmds_Feb83.pdf |access-date=Mar 29, 2022}}</ref>}} |
|||
In 1971, [[Ken Thompson]] developed the [[Thompson shell]] in the first version of Unix. While simpler than the Multics shell, it contained some innovative features, which have been carried forward in modern shells, including the use of < and > for input and output [[Redirection (computing)|redirection]]. |
|||
⚫ | In addition to shells running on local systems, there are different ways to make remote systems available to local users; such approaches are usually referred to as |
||
The graphical shell first appeared in [[Douglas Engelbart]]’s [[NLS (computer system)|NLS]] system, demonstrated in December, 1968 at the [[Fall Joint Computer Conference]] in San Francisco, in what has been called ''[[The Mother of All Demos]]''. Engelbart’s colleagues at [[Stanford Research Institute]] brought the concept to the Xerox [[Palo Alto Research Center]] (PARC), where it appeared on the [[Xerox Alto|Alto]], introduced in 1973. From there the idea spread to [[Niklaus Wirth]]’s [[Lilith (computer)|Lilith]] in 1980, and the [[Apple Inc.|Apple]] [[Apple Lisa|Lisa]] in 1983, then became ubiquitous. |
|||
⚫ | Most operating system shells fall into one of two categories{{snd}} command-line and graphical. Command |
||
== |
== {{Anchor|CLI}}Command-line shells == |
||
{{See also|List of command-line interpreters}} |
{{See also|List of command-line interpreters}} |
||
[[File:Dir command in Windows Command Prompt.png|thumb|right|upright=1.7|[[Windows Command Prompt|Command Prompt]], a CLI shell in Windows]] |
[[File:Dir command in Windows Command Prompt.png|thumb|right|upright=1.7|[[Windows Command Prompt|Command Prompt]], a CLI shell in Windows]] |
||
[[File:Bash demo.png|thumb|right|upright=1.7|[[Bash (Unix shell)|Bash]], a widely adopted [[Unix shell]] ]] |
[[File:Bash demo.png|thumb|right|upright=1.7|[[Bash (Unix shell)|Bash]], a widely adopted [[Unix shell]] ]] |
||
⚫ | A [[command-line interface]] (CLI) is an operating system shell that uses [[alphanumeric]] characters typed on a keyboard to provide instructions and data to the operating system, interactively. For example, a [[teletypewriter]] can send codes representing keystrokes to a command interpreter program running on the computer; the command interpreter parses the sequence of keystrokes and responds with an error message if it cannot recognize the sequence of characters, or it may carry out some other program action such as loading an application program, listing files, logging in a user and many others. Operating systems such as UNIX have a large variety of [[Unix shell|shell]] programs with different commands, syntax and capabilities, with the [[POSIX shell]] being a baseline. Some operating systems had only a single style of command interface; commodity operating systems such as [[MS-DOS]] came with a standard command interface ([[COMMAND.COM]]) but third-party interfaces were also often available, providing additional features or functions such as menuing or remote program execution. |
||
⚫ | A [[command-line interface]] (CLI) is an operating system shell that uses alphanumeric characters typed on a keyboard to provide instructions and data to the operating system, interactively. For example, a [[teletypewriter]] can send codes representing keystrokes to a command interpreter program running on the computer; the command interpreter parses the sequence of keystrokes and responds with an error message if it cannot recognize the sequence of characters, or it may carry out some other program action such as loading an application program, listing files, logging in a user and many others. Operating systems such as UNIX have a large variety of [[Unix shell|shell]] programs with different commands, syntax and capabilities. Some operating systems had only a single style of command interface; commodity operating systems such as [[MS-DOS]] came with a standard command interface but third-party interfaces were also often available, providing additional features or functions such as menuing or remote program execution. |
||
Application programs may also implement a command-line interface. For example, in Unix-like systems, the [[telnet]] program has a number of commands for controlling a link to a remote computer system. Since the commands to the program are made of the same keystrokes as the data being sent to a remote computer, some means of distinguishing the two are required. An [[escape sequence]] can be defined, using either a special local keystroke that is never passed on but always interpreted by the local system. The program becomes modal, switching between interpreting commands from the keyboard or passing keystrokes on as data to be processed. |
Application programs may also implement a command-line interface. For example, in Unix-like systems, the [[telnet]] program has a number of commands for controlling a link to a remote computer system. Since the commands to the program are made of the same keystrokes as the data being sent to a remote computer, some means of distinguishing the two are required. An [[escape sequence]] can be defined, using either a special local keystroke that is never passed on but always interpreted by the local system. The program becomes modal, switching between interpreting commands from the keyboard or passing keystrokes on as data to be processed. |
||
Line 31: | Line 45: | ||
A feature of many command-line shells is the ability to save sequences of commands for re-use. A data file can contain sequences of commands which the CLI can be made to follow as if typed in by a user. Special features in the CLI may apply when it is carrying out these stored instructions. Such [[batch files]] (script files) can be used repeatedly to automate routine operations such as initializing a set of programs when a system is restarted. Batch mode use of shells usually involves structures, conditionals, variables, and other elements of programming languages; some have the bare essentials needed for such a purpose, others are very sophisticated programming languages in and of themselves. Conversely, some programming languages can be used interactively from an operating system shell or in a purpose-built program. |
A feature of many command-line shells is the ability to save sequences of commands for re-use. A data file can contain sequences of commands which the CLI can be made to follow as if typed in by a user. Special features in the CLI may apply when it is carrying out these stored instructions. Such [[batch files]] (script files) can be used repeatedly to automate routine operations such as initializing a set of programs when a system is restarted. Batch mode use of shells usually involves structures, conditionals, variables, and other elements of programming languages; some have the bare essentials needed for such a purpose, others are very sophisticated programming languages in and of themselves. Conversely, some programming languages can be used interactively from an operating system shell or in a purpose-built program. |
||
Several command-line shells, such as [[Nushell]], Xonsh, [[Bash (Unix shell)]], and [[Z shell]], offer [[command-line completion]], enabling the interpreter to expand commands based on a few characters input by the user.<ref>[https://xon.sh/ Xonsh Official Website]</ref> |
|||
⚫ | |||
⚫ | A command-line interpreter may offer a history function, so that the user can recall earlier commands issued to the system and repeat them, possibly with some editing. Since all commands to the operating system had to be typed by the user, short command names and compact systems for representing program options were common. Short names were sometimes hard for a user to recall, and early systems lacked the storage resources to provide a detailed on-line user instruction guide. |
||
The first [[Unix shell]], [[Ken Thompson]]'s ''sh'',<ref name="v6hist"/> was modeled after the [[Multics]] shell,<ref name="Vleck"/> itself modeled after the [[RUNCOM]]<ref name="Pouzin"/> program [[Louis Pouzin]] showed to the Multics Team. The "rc" suffix on some Unix configuration files (for example, ".vimrc"), is a remnant of the RUNCOM ancestry of Unix shells.{{Citation needed|date=December 2011}} |
|||
== {{Anchor|GUI}}Graphical shells == |
== {{Anchor|GUI}}Graphical shells == |
||
{{Main|Graphical user interface}} |
|||
A graphical user interface (GUI) provides means for manipulating programs graphically, by allowing for operations such as opening, closing, moving and resizing [[window (computing)|windows]], as well as switching [[focus (computing)|focus]] between windows. Graphical shells may be included with [[desktop environment]]s or come separately, even as a set of loosely coupled utilities. |
|||
Most graphical user interfaces develop the [[Desktop metaphor|metaphor of an "electronic desktop"]], where data files are represented as if they were paper documents on a desk, and application programs similarly have graphical representations instead of being invoked by command names. |
Most graphical user interfaces develop the [[Desktop metaphor|metaphor of an "electronic desktop"]], where data files are represented as if they were paper documents on a desk, and application programs similarly have graphical representations instead of being invoked by command names. |
||
⚫ | |||
⚫ | |||
⚫ | Graphical shells typically build on top of a [[windowing system]]. In the case of [[X Window System]] or [[Wayland (display server protocol)|Wayland]], the shell consists of an [[X window manager]] or a [[Wayland compositor]], respectively, as well as of one or multiple programs providing the functionality to start installed applications, to manage open windows and virtual desktops, and often to support a widget engine. |
||
⚫ | In the case of [[macOS]], [[Quartz Compositor]] acts as the windowing system, and the shell consists of the [[Finder (software)|Finder]],<ref name="loginwindow">{{cite web|url=https://developer.apple.com/library/mac/documentation/macosx/conceptual/bpsystemstartup/chapters/Lifecycle.html|title=The Life Cycle of a Daemon|publisher=[[Apple Inc.]]}}</ref> the [[Dock (macOS)|Dock]],<ref name="loginwindow"/> SystemUIServer,<ref name="loginwindow"/> and [[Mission Control (macOS)|Mission Control]].<ref>{{cite web|url=http://osxdaily.com/2011/11/23/restart-mission-control-in-os-x-lion/|title=Restart Mission Control in OS X Lion|publisher=OSXDaily|date=Nov 23, 2011}}</ref> |
||
=== Microsoft Windows === |
=== Microsoft Windows === |
||
{{main|Windows shell|Windows shell replacement|Program Manager}} |
{{main|Windows shell|Windows shell replacement|Program Manager}} |
||
⚫ | Modern versions of the Microsoft Windows operating system use the [[Windows shell]] as their shell. Windows Shell provides [[desktop environment]], [[start menu]], and [[task bar]], as well as a [[graphical user interface]] for accessing the file management functions of the operating system. Older versions also include [[Program Manager]], which was the shell for the 3.x series of Microsoft Windows, and which in fact shipped with later versions of Windows of both the 95 and NT types at least through Windows XP. The interfaces of Windows versions 1 and 2 were markedly different. |
||
⚫ | Desktop applications are also considered shells, as long as they use a third-party engine. Likewise, many individuals and developers dissatisfied with the interface of Windows Explorer have developed software that either alters the functioning and appearance of the shell or replaces it entirely. [[WindowBlinds]] by [[StarDock]] is a good example of the former sort of application. [[LiteStep]] and Emerge Desktop are good examples of the latter. |
||
⚫ | Modern versions of the |
||
⚫ | Interoperability programmes and purpose-designed software lets Windows users use equivalents of many of the various Unix-based GUIs discussed below, as well as Macintosh. An equivalent of the OS/2 Presentation Manager for version 3.0 can run some OS/2 programmes under some conditions using the OS/2 [[Architecture of Windows NT#User mode|environmental subsystem]] in versions of Windows NT. |
||
[[File:Taskbar-SharpEnviro-v8.png|thumb|right|650px|The [[taskbar]] of [[SharpEnviro]], which is a shell replacement for Windows]] |
|||
⚫ | Desktop applications are also considered shells, as long as they use a third-party engine. Likewise, many individuals and developers dissatisfied with the interface of Windows Explorer have developed software that either alters the functioning and appearance of the shell or replaces it entirely. [[WindowBlinds]] by [[StarDock]] is a good example of the former sort of application. [[LiteStep |
||
⚫ | Interoperability programmes and purpose-designed software lets Windows users use equivalents of many of the various Unix-based GUIs discussed below, as well as Macintosh. An equivalent of the OS/2 Presentation Manager for version 3.0 can run some OS/2 programmes under some conditions using the OS/2 [[Architecture of Windows NT#User mode|environmental subsystem]] in versions of Windows NT |
||
⚫ | |||
⚫ | |||
⚫ | Graphical shells typically build on top of a [[windowing system]]. In the case of [[X Window System]] or [[Wayland (display server protocol)|Wayland]], the shell consists of an [[X window manager]] or a [[Wayland compositor]], respectively, as well as of one or multiple programs providing the functionality to start installed applications, to manage open windows and virtual desktops, and often to support a widget engine. |
||
⚫ | In the case of [[ |
||
== Other uses == |
== Other uses == |
||
⚫ | "Shell" is also used loosely to describe application software that is "built around" a particular component, such as web browsers and email clients, in analogy to the shells found in nature. Indeed, the (command-line) shell encapsulates the operating system ''kernel''. These are also sometimes referred to as "wrappers".<ref name="JargonFile"/> |
||
⚫ | |||
In [[expert system]]s, a shell is a piece of software that is an "empty" expert system without the knowledge base for any particular application.<ref name="BCS"/> |
In [[expert system]]s, a shell is a piece of software that is an "empty" expert system without the knowledge base for any particular application.<ref name="BCS"/> |
||
== See also == |
== See also == |
||
⚫ | |||
{{Portal|Computing}} |
|||
⚫ | |||
* [[Comparison of command shells]] |
* [[Comparison of command shells]] |
||
⚫ | |||
* [[Human–computer interaction]] |
* [[Human–computer interaction]] |
||
* [[Internet Explorer shell]] |
* [[Internet Explorer shell]] |
||
Line 75: | Line 82: | ||
* [[Shell builtin]] |
* [[Shell builtin]] |
||
* [[Superuser]] |
* [[Superuser]] |
||
⚫ | |||
* [[Window manager]]{{snd}} provides a rudimentary process management interface |
* [[Window manager]]{{snd}} provides a rudimentary process management interface |
||
* [[Read–eval–print loop]] also called ''language shell'', a [[command line interface|CLI]] for an interpreted [[programming language]] |
|||
{{ |
{{div col end}} |
||
== References == |
== References == |
||
{{reflist|30em|refs= |
{{reflist|30em|refs= |
||
<ref name="BCS">{{ cite book | url = |
<ref name="BCS">{{ cite book | url = https://books.google.com/books?id=g8Bds8ssYYgC&dq=%22shell+is+a+piece%22+%22expert+system%22&pg=PA135 | title = British Computer Society: The BCS glossary of ICT and computing terms | publisher = Pearson Education | year = 2005 | isbn = 978-0-13-147957-9 | pages = 135 }}</ref> |
||
<ref name="v6hist">{{ cite web|url=http://v6shell.org/history/ |title=V6 Thompson Shell Port - History |publisher=V6shell.org |date= |accessdate=2012-08-14 }}</ref> |
|||
<ref name="Vleck">{{ cite web|author=Tom Van Vleck |url=http://www.multicians.org/unix.html |title=Unix and Multics |publisher=Multicians.org |date=1995-02-05 |accessdate=2012-08-14 }}</ref> |
|||
<ref name="Pouzin">{{ cite web|author=Louis Pouzin |url=http://www.multicians.org/shell.html |title=The Origin of the Shell |publisher=Multicians.org |date=2000-11-25 |accessdate=2012-08-14 }}</ref> |
|||
}} |
}} |
||
{{Desktop environments and window managers for X11 and Wayland}} |
|||
{{Unix shells}} |
|||
{{Operating system}} |
|||
[[Category:Command shells| ]] |
[[Category:Command shells| ]] |
Latest revision as of 04:20, 2 December 2024
In computing, a shell is a computer program that exposes an operating system's services to a human user or other programs. In general, operating system shells use either a command-line interface (CLI) or graphical user interface (GUI), depending on a computer's role and particular operation. It is named a shell because it is the outermost layer around the operating system.[1][2]
Overview
[edit]Operating systems provide various services to their users, including file management, process management (running and terminating applications), batch processing, and operating system monitoring and configuration.
Most operating system shells are not direct interfaces to the underlying kernel, even if a shell communicates with the user via peripheral devices attached to the computer directly. Shells are actually special applications that use the kernel API in just the same way as it is used by other application programs. A shell manages the user–system interaction by prompting users for input, interpreting their input, and then handling output from the underlying operating system (much like a read–eval–print loop, REPL).[3] Since the operating system shell is actually an application, it may easily be replaced with another similar application, for most operating systems.
In addition to shells running on local systems, there are different ways to make remote systems available to local users; such approaches are usually referred to as remote access or remote administration. Initially available on multi-user mainframes, which provided text-based UIs for each active user simultaneously by means of a text terminal connected to the mainframe via serial line or modem, remote access has extended to Unix-like systems and Microsoft Windows. On Unix-like systems, Secure Shell protocol (SSH) is usually used for text-based shells, while SSH tunneling can be used for X Window System–based graphical user interfaces (GUIs). On Microsoft Windows, Remote Desktop Protocol can be used to provide GUI remote access, and since Windows Vista, PowerShell Remote can be used for text-based remote access via WMI, RPC, and WS-Management.[4]
Most operating system shells fall into one of two categories – command-line and graphical. Command-line shells provide a command-line interface (CLI) to the operating system, while graphical shells provide a graphical user interface (GUI). Other possibilities, although not so common, include a voice user interface and various implementations of a text-based user interface (TUI) that are not CLI, such as text-based menu systems. The relative merits of CLI- and GUI-based shells are often debated. Many computer users use both depending on the task to be performed.
History
[edit]Early interactive systems provided a simple command-line interpreter as part of the resident monitor. This interpreter might be called by different names, such as COMCON
on DEC TOPS-10 systems.[5] The interpreter would execute one of a number of predefined commands, one of which would be to run a user program. Common commands would log the user on and off the system, allocate, free, and manipulate devices and files, and query various pieces of information about the system or a user process.[6]
The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, as if it were called from the inside of another program. Hereafter, for simplification, we shall refer to that procedure as the "SHELL".
In 1964, for the Multics operating system, Louis Pouzin conceived the idea of "using commands somehow like a programming language," and coined the term shell to describe it.[8] In a 1965 document, the shell is defined as "a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control. This procedure acts as an interface between console messages and subroutine [in the supervisor]."[9] This system was first implemented by Glenda Schroeder and an unnamed man from General Electric.[10]
Multics also introduced the active function, a key concept in all later shells. This is defined as
a string... which is replaced by a character string return value before the command line containing it is executed. Active functions are often used... to implement command-language macros.[11]
In 1971, Ken Thompson developed the Thompson shell in the first version of Unix. While simpler than the Multics shell, it contained some innovative features, which have been carried forward in modern shells, including the use of < and > for input and output redirection.
The graphical shell first appeared in Douglas Engelbart’s NLS system, demonstrated in December, 1968 at the Fall Joint Computer Conference in San Francisco, in what has been called The Mother of All Demos. Engelbart’s colleagues at Stanford Research Institute brought the concept to the Xerox Palo Alto Research Center (PARC), where it appeared on the Alto, introduced in 1973. From there the idea spread to Niklaus Wirth’s Lilith in 1980, and the Apple Lisa in 1983, then became ubiquitous.
Command-line shells
[edit]A command-line interface (CLI) is an operating system shell that uses alphanumeric characters typed on a keyboard to provide instructions and data to the operating system, interactively. For example, a teletypewriter can send codes representing keystrokes to a command interpreter program running on the computer; the command interpreter parses the sequence of keystrokes and responds with an error message if it cannot recognize the sequence of characters, or it may carry out some other program action such as loading an application program, listing files, logging in a user and many others. Operating systems such as UNIX have a large variety of shell programs with different commands, syntax and capabilities, with the POSIX shell being a baseline. Some operating systems had only a single style of command interface; commodity operating systems such as MS-DOS came with a standard command interface (COMMAND.COM) but third-party interfaces were also often available, providing additional features or functions such as menuing or remote program execution.
Application programs may also implement a command-line interface. For example, in Unix-like systems, the telnet program has a number of commands for controlling a link to a remote computer system. Since the commands to the program are made of the same keystrokes as the data being sent to a remote computer, some means of distinguishing the two are required. An escape sequence can be defined, using either a special local keystroke that is never passed on but always interpreted by the local system. The program becomes modal, switching between interpreting commands from the keyboard or passing keystrokes on as data to be processed.
A feature of many command-line shells is the ability to save sequences of commands for re-use. A data file can contain sequences of commands which the CLI can be made to follow as if typed in by a user. Special features in the CLI may apply when it is carrying out these stored instructions. Such batch files (script files) can be used repeatedly to automate routine operations such as initializing a set of programs when a system is restarted. Batch mode use of shells usually involves structures, conditionals, variables, and other elements of programming languages; some have the bare essentials needed for such a purpose, others are very sophisticated programming languages in and of themselves. Conversely, some programming languages can be used interactively from an operating system shell or in a purpose-built program.
Several command-line shells, such as Nushell, Xonsh, Bash (Unix shell), and Z shell, offer command-line completion, enabling the interpreter to expand commands based on a few characters input by the user.[12]
A command-line interpreter may offer a history function, so that the user can recall earlier commands issued to the system and repeat them, possibly with some editing. Since all commands to the operating system had to be typed by the user, short command names and compact systems for representing program options were common. Short names were sometimes hard for a user to recall, and early systems lacked the storage resources to provide a detailed on-line user instruction guide.
Graphical shells
[edit]A graphical user interface (GUI) provides means for manipulating programs graphically, by allowing for operations such as opening, closing, moving and resizing windows, as well as switching focus between windows. Graphical shells may be included with desktop environments or come separately, even as a set of loosely coupled utilities.
Most graphical user interfaces develop the metaphor of an "electronic desktop", where data files are represented as if they were paper documents on a desk, and application programs similarly have graphical representations instead of being invoked by command names.
Unix-like systems
[edit]Graphical shells typically build on top of a windowing system. In the case of X Window System or Wayland, the shell consists of an X window manager or a Wayland compositor, respectively, as well as of one or multiple programs providing the functionality to start installed applications, to manage open windows and virtual desktops, and often to support a widget engine.
In the case of macOS, Quartz Compositor acts as the windowing system, and the shell consists of the Finder,[13] the Dock,[13] SystemUIServer,[13] and Mission Control.[14]
Microsoft Windows
[edit]Modern versions of the Microsoft Windows operating system use the Windows shell as their shell. Windows Shell provides desktop environment, start menu, and task bar, as well as a graphical user interface for accessing the file management functions of the operating system. Older versions also include Program Manager, which was the shell for the 3.x series of Microsoft Windows, and which in fact shipped with later versions of Windows of both the 95 and NT types at least through Windows XP. The interfaces of Windows versions 1 and 2 were markedly different.
Desktop applications are also considered shells, as long as they use a third-party engine. Likewise, many individuals and developers dissatisfied with the interface of Windows Explorer have developed software that either alters the functioning and appearance of the shell or replaces it entirely. WindowBlinds by StarDock is a good example of the former sort of application. LiteStep and Emerge Desktop are good examples of the latter.
Interoperability programmes and purpose-designed software lets Windows users use equivalents of many of the various Unix-based GUIs discussed below, as well as Macintosh. An equivalent of the OS/2 Presentation Manager for version 3.0 can run some OS/2 programmes under some conditions using the OS/2 environmental subsystem in versions of Windows NT.
Other uses
[edit]"Shell" is also used loosely to describe application software that is "built around" a particular component, such as web browsers and email clients, in analogy to the shells found in nature. Indeed, the (command-line) shell encapsulates the operating system kernel. These are also sometimes referred to as "wrappers".[2]
In expert systems, a shell is a piece of software that is an "empty" expert system without the knowledge base for any particular application.[15]
See also
[edit]- Comparison of command shells
- Human–computer interaction
- Internet Explorer shell
- Shell account
- Shell builtin
- Superuser
- Unix shell
- Window manager – provides a rudimentary process management interface
- Read–eval–print loop also called language shell, a CLI for an interpreted programming language
References
[edit]- ^ "The Internet's fifth man", Brain scan, The Economist, London: Economist Group, December 13, 2013,
Mr Pouzin created a program called RUNCOM that helped users automate tedious and repetitive commands. That program, which he described as a "shell" around the computer's whirring innards, gave inspiration—and a name—to an entire class of software tools, called command-line shells, that still lurk below the surface of modern operating systems.
- ^ a b Raymond, Eric S. (ed.). "shell". The Jargon File.
- ^ "Operating system shells". AIX 6.1 Information Center. IBM Corp. Retrieved September 16, 2012.
- ^ Wheeler, Sean (14 October 2018). "Running Remote Commands". Microsoft Docs. Microsoft. Retrieved 30 June 2019.
You can run commands on one or hundreds of computers with a single PowerShell command. Windows PowerShell supports remote computing by using various technologies, including WMI, RPC, and WS-Management.
- ^ Digital Equipment Corporation (Nov 1980). TOPS-10 MONITOR INTERNALS (PDF). pp. CMND-1–CMND-16. Retrieved Mar 29, 2022.
- ^ Digital Equipment Corporation (Aug 1977). DECSystem 10 Operating System Commands Manual (PDF). Retrieved Mar 29, 2022.
- ^ Poizin, Louis. "The SHELL: A Global Tool for Calling and Chaining Procedures in the System" (PDF).
- ^ Pouzin, Louis. "The Origin of the Shell". multicians.org. Retrieved Mar 29, 2022.
- ^ Pouzin, Louis. "The SHELL: A Global Tool for Calling and Chaining Procedures in the System" (PDF). MIT.edi. Retrieved Mar 29, 2022.
- ^ Pouzin, Louis. "The Origin of the Shell". multicians.org. Retrieved Feb 12, 2024.
- ^ Honeywell, inc. (Feb 1983). Multics Common Commands (PDF). pp. 1-1–1-2. Retrieved Mar 29, 2022.
- ^ Xonsh Official Website
- ^ a b c "The Life Cycle of a Daemon". Apple Inc.
- ^ "Restart Mission Control in OS X Lion". OSXDaily. Nov 23, 2011.
- ^ British Computer Society: The BCS glossary of ICT and computing terms. Pearson Education. 2005. p. 135. ISBN 978-0-13-147957-9.