¿Por qué se utilizó la palabra "shell" para describir una interfaz de línea de comandos?

Tengo curiosidad sobre el término "concha". Creo que sé lo que es (aunque la distinción entre "shell" y "terminal" todavía es confusa), pero ¿por qué se eligió la palabra "shell" para describir este tipo de programa?

Esto puede parecer poco importante, pero generalmente cuando la elección de palabras me desconcierta, está apuntando a una brecha en mi comprensión.

El glosario Multics puede proporcionar una pista. El shell se define así:

El procesador de comandos de Multics solía llamarse shell. Este programa recibe una línea de comando para que el oyente lo ejecute; analiza la línea en un nombre de comando y argumentos, localiza el comando y lo inicia, y llama al programa de comando con argumentos que son cadenas de caracteres PL / I. Es simple reemplazar el shell suministrado por el sistema predeterminado con un programa proporcionado por el usuario, llamando a cu_ $ set_cp (ver abrev). Un shell de Unix incluye los conceptos de shell y de escucha en el sentido de Multics.

La relación entre shell y oyente tiene sentido tanto etimológica como metafóricamente [1].

[1] "Dado que el caparazón es un símbolo de autoridad, habla y oído, es decir, un símbolo de profecía ..."

La analogía es con una nuez : afuera está la cáscara, adentro está el núcleo.

De http://en.wikipedia.org/wiki/Thompson_shell#History

"El nombre" shell "para un intérprete de línea de comandos y el concepto de convertir el shell en un programa de usuario fuera del núcleo del sistema operativo se introdujeron en Multics precursor de Unix".

Más abajo en la madriguera del conejo de Wikipedia se encuentra esto: "Louis Pouzin, introdujo el término shell para el lenguaje de comando utilizado en Multics"

No lo he leído en su totalidad, pero su escrito aquí puede darle la respuesta: http://www.multicians.org/shell.html

EDITAR: de hecho, no se explica. Él simplemente "acuñó" el término. No es la historia divertida que esperabas, ¿verdad?

¿Quizás porque es la superficie, protegiendo el núcleo interno del usuario? Entonces el grano sería la perla dentro del caparazón.

Parece que la respuesta yace aquí:

Nota histórica: Aparentemente, el shell Multics original (sentido 1) se llamó así porque era un shell (sentido 3); ejecutó programas de usuario no iniciando procesos separados, sino vinculando dinámicamente los programas en su propio código, llamándolos como subrutinas, y luego desvinculándolos dinámicamente al regresar. El intérprete de comandos de VMS todavía hace algo muy parecido a esto.

- Wikipedia

Es decir, "shell" era una buena analogía del mundo real de cómo Multics, un predecesor de Unix, ejecutaba programas.

Según tengo entendido, "shell" es un término antiguo para lo que ahora llamaríamos "Interfaz de usuario principal". El término análogo moderno sería "Entorno de escritorio", ya que prácticamente todos los sistemas modernos utilizan la metáfora del escritorio.

El núcleo es el núcleo del sistema, mientras que el shell lo rodea y es la interfaz entre el núcleo y el usuario.

Dentro de cualquier sistema UNIX, e incluso con sistemas Linux, el shell es el lugar donde los administradores de sistemas trabajan para configurar y administrar un sistema.

La terminología moderna a menudo usa el término CLI o interfaz de línea de comando para describir el indicador de comandos de shell. Esto es en deferencia a la GUI o interfaz gráfica de usuario. Sin embargo, cualquier Sysadmin real sabe que no debe usar herramientas GUI para configurar UNIX / Linux y trabajar solo directamente en el símbolo del sistema de shell.

Esto es aún más relevante hoy en día cuando escuchamos a algunos entusiastas jóvenes de Linux decir cosas como "Yo uso Linux, pero realmente no he aprendido la CLI".

Como dice el viejo adagio "Si no puede hacerlo en el intérprete de comandos de shell, no puede hacerlo".