I'm curious about the term "shell." I think I know what it is (though the distinction between "shell" and "terminal" is still fuzzy) but why was the word "shell" chosen to describe this type of program?
This might seem unimportant, but usually when the word choices mystifies me, it is pointing to a gap in my understanding.
The analogy is with a nut: outside is the shell, inside is the kernel.
Maybe because it is the surface, shielding the inner kernel from the user? So the kernel would be the pearl inside the shell.
From http://en.wikipedia.org/wiki/Thompson_shell#History
"The name "shell" for a command line interpreter and the concept of making the shell a user program outside of the operating system kernel were introduced in Unix's precursor Multics."
Further down the wikipedia rabbit hole finds this: "Louis Pouzin, introduced the term shell for the command language used in Multics"
I have not read it in full, but his writing here may give you the answer: http://www.multicians.org/shell.html
EDIT: indeed it is not explained. He merely "coined" the term. Not the funny story you were hoping for, was it?
The Multics glossary may provide a clue. The shell is defined thus:
The Multics command processor used to be called the shell. This program is passed a command line for execution by the listener; it parses the line into a command name and arguments, locates the command and initiates it, and calls the command program with arguments that are PL/I character strings. It is simple to replace the default system supplied shell with a user-provided program, by calling cu_$set_cp (see abbrev). A Unix shell includes the concepts of both shell and listener in the Multics sense.
The relationship between shell and listener makes sense both etymologically and metaphorically [1].
[1] "Since the shell is a symbol of authority, speech, and hearing, which is to say a symbol of prophecy..."
Looks like the answer lies here:
Historical note: Apparently, the original Multics shell (sense 1) was so called because it was a shell (sense 3); it ran user programs not by starting up separate processes, but by dynamically linking the programs into its own code, calling them as subroutines, and then dynamically de-linking them on return. The VMS command interpreter still does something very like this.
I.e., "shell" was a good real world analogy for how Multics, a predecessor of Unix, ran programs.
As I understand it, "shell" is an older term for what we now would call "Primary User Interface". The modern analogous term would be "Desktop Environment", since virtualy all modern systems use the desktop metaphor.
The kernel is the core of the system, whilst the shell surrounds it and is the interface between the kernel and the user.
Within any UNIX system, and even with Linux systems, the shell is the place that systems administrators work to configure and manage a system.
Modern terminology often uses the term CLI or command line interface to describe the shell prompt. This is in deference to the GUI or graphical user interface. However any real Sysadmin knows that you should not use GUI tools to configure a UNIX/Linux and work only directly at the shell command prompt.
This is even more relevant nowadays when we hear some junior Linux enthusiasts say things such as "I use linux, but I've not really learnt the CLI".
As the old adage goes "If you can't do it at the shell prompt, you can't do it."
It's called a SHELL as it hides the kernel. like the bullet shell casing. It protects the kernel.
