¿Por qué hay múltiples shells en un sistema tipo Unix?

Acabo de empezar a aprender los fundamentos de Unix y me pregunto por qué hay tantos shells en un sistema similar a Unix. Del libro Programación avanzada en Unix Environment :

Un shell es un intérprete de línea de comandos que lee la entrada del usuario y ejecuta comandos. La entrada del usuario a un shell normalmente proviene del terminal (un shell interactivo) o, a veces, de un archivo (llamado script de shell).

Y luego el libro continúa enumerando una serie de programas de shell como Bourne shell, Bourne-again shell, Cshell, etc. Mi pregunta es básicamente ¿por qué necesitamos múltiples proyectiles?

La mayoría de los shells utilizados en entornos UNIX modernos están destinados a cumplir con la especificación POSIX sh. POSIX sh se deriva del shell Korn original (ksh88), que a su vez se deriva del shell Bourne anterior, pero POSIX sh solo especifica un pequeño subconjunto de incluso la funcionalidad de ksh88. A un shell que solo implementa el requisito mínimo le faltan muchas características requeridas para escribir todos los scripts menos los más triviales de una manera segura y razonable. Por ejemplo, las variables locales y las matrices son extras no estándar.

Por lo tanto, la primera razón es extender el shell con características adicionales. Las diferentes conchas eligen enfocarse en diferentes cosas. Por ejemplo, Zsh se enfoca en características interactivas avanzadas mientras que ksh93 (el shell korn "original" actual) se enfoca en potentes características de programación y rendimiento. Incluso los shells muy mínimos como Dash agregan al menos algunos extras no estándar como las variables locales.

Las características adicionales rara vez son ampliamente interoperables, si es que lo hacen. La mayor parte del conjunto de características ksh88 es bastante interoperable, como la sintaxis de globbing extendida, pero con características no estándar, no hay garantías, y realmente debe saber qué está haciendo para usarlas de forma portátil.

La segunda razón es el legado. Todavía hay muchos Unix patentados que usan implementaciones antiguas no estándar para su / bin / sh. Hasta hace poco, Solaris todavía usaba Bourne como su defuault y eligió mantener el shell Heirloom en lugar de actualizarse a algo moderno. Estos sistemas generalmente vienen con diferentes shells a los que puede cambiar, por ejemplo, cambiando su variable PATH o alterando shebangs dentro de scripts individuales.

Entonces para resumir. Hay múltiples shells, a menudo por defecto:

• Para características adicionales, especialmente para tratar con extras no portátiles.
• Para manejar scripts heredados que a menudo no se mantienen.
• Tamaño / rendimiento. Los sistemas integrados a menudo requieren pequeños shells como mksh u busybox sh.
• Razones de licencia. AT&T ksh fue un software propietario hasta alrededor de 2000 más o menos. Esto es en gran medida lo que dio lugar a todos los clones similares a ksh como Zsh y Bash.
• Otras razones históricas. Aunque hoy no es muy popular, ha habido intentos radicales de rediseñar el lenguaje, como scsh y es. La función de sustitución de proceso de muchos shells proviene originalmente de rc (con una sintaxis un poco diferente) y la expansión de llaves de csh. Diferentes shells tienen diferentes combinaciones de tales características disponibles, generalmente con algunas diferencias sutiles o no tan sutiles.

Porque las personas tienen diferentes necesidades y es bueno tener alternativas que se ajusten a sus necesidades en la situación dada. Un shell es solo una herramienta en sí mismo y, en mi opinión, debería ser reemplazado por cualquier otro. Ese es el poder de Unix / Linux, opuesto a lo que Microsoft Windows ha elegido ser.

Del mismo modo ... ¿Por qué hay tantos editores de texto? ¿Por qué las personas desarrollan un nuevo navegador si ya hay uno? ¿Por qué hay GNOME, KDE, Xfce, LXDE, E17, etc.?

Respuesta corta

Debido a un extraño historial de licencias, ninguna entidad ha desarrollado Unix. Fue un proceso comunitario en el que participaron tanto voluntarios como corporaciones. Estas entidades no siempre compartían todas sus herramientas, por lo que ocurrieron conchas separadas. Cuando nos dimos cuenta de lo contraproducente que es esto, ya era demasiado tarde para unificar todas las conchas en uso. En cambio, se ha trabajado para garantizar que todas estas capas sean (teóricamente) compatibles entre sí .

La respuesta larga es compleja y está estrechamente vinculada a la historia de Unix. No hay forma de que mantenga una sola respuesta en esta página, pero ha sido ampliamente documentada. Encontrará respuestas más detalladas y precisas al revisar la web y los libros relacionados con la historia de Unix.

Existen diferentes shells por los mismos motivos que existen los diferentes navegadores web: todos tienen una preferencia y algunos shells tienen un bagaje o impulso histórico. Cada uno tiene diferentes características e idiosincrasias.

Sobre todo, historia ...

Bourne se desarrolló como parte de (la propiedad) SysV Unix, mientras que BSD utilizó csh... Más tarde, bash se desarrolló como una alternativa de código abierto al shell Bourne (y sus versiones mejoradas, como ksh). Se adoptó un shell similar a Bourne en el estándar POSIX. ksh es compatible y bash puede ser compatible.

A los shells les gusta cshy tcshes mucho más fácil de usar de forma interactiva que el shell Bourne original (que carece de finalización de comandos, etc.) pero son horribles para la creación de scripts ...

En algunos entornos, como los sistemas integrados basados ​​en Unix, las características de script, el tamaño y la velocidad son más importantes que las características interactivas como la finalización de comandos, y se tiende a utilizar una variante diferente de los shells.

Para las secuencias de comandos portátiles, debe usar una variante Bourne compatible con POSIX y evitar las extensiones.