Mejor respuesta
Estos son todos shells, y hay muchos más que no mencionaste. Cuál elija usar es una cuestión de preferencia personal.
El primer shell fue el Bourne Shell (o sh) y fue el predeterminado en Unix durante mucho tiempo. Luego apareció una derivación importante en Unix y se creó un nuevo shell desde cero llamado C Shell (o csh). El viejo Bourne Shell fue seguido por el compatible pero mucho más poderoso Korn Shell (o ksh). Los shells disponibles generalmente caen en una de estas categorías: derivado Bourne / Korn Shell (bash), derivado o clon de C Shell (tcsh) u «otro» (como zsh).
Hay muchos shells para elegir, y no solo los que mencionaste. GNU bash cae en el campo Bourne / Korn Shell, y es el shell predeterminado en una amplia variedad de variantes de Unix y Linux en la actualidad. Si ha usado un terminal de shell en Unix o Linux, es probable que sea este. Si realmente quiere Bourne Shell (sh), creo que ahora está disponible gratis, pero generalmente se evita porque no tiene suficientes funciones. El Korn Shell es compatible con versiones anteriores y también es gratuito en forma de clones (mksh) y el original recientemente lanzado (ksh).
Para C Shell, existe tcsh, un clon expandido del csh original Hay menos clones de csh porque csh no se ha visto como un camino a seguir y no tiene tantos usuarios; sin embargo, muchas versiones BSD de Unix (como FreeBSD y otras) usarán csh como su shell predeterminado.
Hay variantes que no son compatibles con sh / ksh o csh, pero tienden a ser shells de nicho. Mis favoritos en este espacio serían Scheme Shell (scsh) y Plan 9 shell rc, pero estos nunca se instalan por defecto en Unix o Linux y el primero es bastante grande. zsh también cae en esta categoría «otros».
Mi recomendación es triple: primero, pruebe el shell predeterminado en su sistema – casi con certeza GNU bash. Bash está en todas partes y leerá y ejecutará los programas Bourne Shell y Korn Shell sin incompatibilidades. En segundo lugar, pruebe cada uno de los shells que realmente desea probar (como zsh o tcsh) y trabaje con él durante un tiempo para ver si satisface sus necesidades. Finalmente, use el que más le guste.
Tenga en cuenta que no «t tiene que escribir scripts en el shell que usa: Usé el C Shell de forma interactiva, pero me negué a programar en él (todos mis scripts usaban el Korn Shell). Finalmente, un día me lancé a ksh y nunca miré hacia atrás.
Mis favoritos personales en esto los puntos son mksh (un clon de Korn Shell sin extensiones), o GNU bash con compatibilidad total con Korn Shell, o rc , el shell del nuevo sistema operativo Plan 9 que se suponía que sería un sucesor de Unix (aunque esto no se ha materializado).
Respuesta
¿Mejor para qué?
¿Cuáles son sus criterios?
Personalmente sugiero bash porque es el predeterminado en los sistemas Linux y MacOS X y disponible en todas las demás formas de Unix y en MS Windows a través de Cygwin y es el predeterminado para Microsoft ™ Windows Services for Linux ” (Ubuntu bash capa / subsistema de soporte).
Básicamente, es el camino de menor resistencia si va a operar muchos sistemas diferentes a lo largo de muchos años … y con frecuencia accederá a sistemas con nuevas imágenes o instancias recién lanzadas con desviaciones mínimas de la base del sistema operativo (como es común para granjas de servidores web / de aplicaciones escaladas). Está lo suficientemente cerca del shell Korn que pocas personas encontrarán los casos de esquina en los que difieren en semántica. (La mayoría de los usuarios no notarán la diferencia entre clones de shell Bourne más mínimos, como ash y dash y las características que agrega bash , y mucho menos poder distinguir entre las diferencias entre ksh y bash .
zsh es probablemente el más poderoso y personalizable. Es más adecuado para alguien a quien realmente le apasiona usar y personalizar su caparazón. La desventaja de usarlo … con todas sus mejoras y personalizaciones … es que es probable que al usuario le resulte frustrante dejar de usar otro caparazón cuando problemas de depuración en sistemas donde zsh no se ha instalado (todavía), que es algo que la gente de operaciones / administradores de sistemas en entornos modernos hace con bastante frecuencia.También es bastante poco práctico cuando se trabaja con colegas o se les da tutoría y se trata de mostrarles algo en el indicador de shell o compartir una pantalla GNU o tmux sesión con ellos.
El shell Korn, ksh , es un shell mejor para scripts que bash en algunos detalles menores … pero no lo suficiente como para que valga la pena tener que buscarlo, instalarlo y configurarlo en todas partes.
ksh admitió «matrices asociativas» (hash / diccionarios) durante muchos años antes de que bash lo añadiera. (Solo se agregó a bash hace unos años, todavía no está incluido en las versiones que vienen con MacOS X por defecto, por ejemplo). Por lo tanto, generalmente es mejor no utilizar matrices asociativas en sus scripts de shell. Si cree que desea sus funciones, por lo general es mejor cambiar a Python, Ruby, Perl, TCL / deseo o cualquiera de una serie de otros lenguajes de scripting de propósito general . Simplemente no hay mucho que ganar cambiando a un shell diferente (en términos de sobrecarga operativa) solo para esa característica.
Lo mismo puede decirse de ksh Coprocesos .
La única otra diferencia notable es una que debe explicarse. Considere el siguiente comando de shell:
unset foo; echo bar | read foo; echo "$foo"
Esto es perfectamente válido en cualquier shell compatible con Bourne. Pero se comportará de manera diferente bajo varios caparazones. Emitirá la cadena «bar» (y una nueva línea) o solo emitirá la línea en blanco.
bash servirá el último, mientras que ksh y zsh funcionarán de la primera manera. La variable de shell «foo» se establecerá en el shell actual. En mi opinión, esa es la semántica preferida.
Pero este es un caso de esquina. Hasta donde yo sé, no está cubierto por las especificaciones de Posix para el shell de Unix; por lo que el hecho de que el comportamiento dependa de la implementación no es un error. Esto es simplemente algo que un experto en el shell debe conocer y probar o solucionar.
La razón de este comportamiento es que el operador «pipe» en el shell es una comunicación entre procesos mecanismo. El shell debe crear una subcapa, que es un subproceso que ejecuta su propia copia de la memoria del proceso principal. Sin embargo, cualquier implementación determinada puede analizar el comando y ejecutar la parte anterior (a la izquierda) del símbolo de la tubería en la subcapa (como lo hacen ksh y zsh ) o después (a la derecha de) la tubería (como lo hizo bash, muy versiones anteriores de ksh (¿antes del lanzamiento de 1983?) y el shell Bourne más antiguo y la mayoría de sus clones, como ash y dash .
Una obra around es usar la agrupación de comandos para asegurarse de que todos los comandos después de la tubería estén «dentro del alcance» con el read integrado así:
unset foo; echo bar | { read foo; echo "$foo"; }
(Por cierto, este ejemplo expone un error sutil que existía en bash antes de 1.4 y que se corrigió a partir de entonces; el analizador utilizado para tratar {} caracteres y tokens ve muy parecido al () (paréntesis). Por lo tanto, solía tolerar omitir ese punto y coma después de mi echo “$ foo” , que era, técnicamente, una desviación de la especificación. El problema es que millones de personas usaban bash y escribían scripts basándose en la suposición de que no necesitaban terminar su comando antes de una llave de cierre, con una punto y coma o una nueva línea. Por lo tanto, algunos de estos antiguos scripts de shell todavía presentan este error más de una década después y solo hay un puñado de personas que conocen el shell lo suficientemente bien como para detectarlo y solucionarlo).
En cuanto al uso interactivo, bash es claramente superior a ksh pero probablemente no esté a la par con zsh para cualquiera que se comprometa a aprender y usar mejoras y personalizaciones muy complicadas.
bash admite la finalización programable de [Tab] y las bibliotecas GNU readline para un control extremadamente flexible sobre las combinaciones de teclas, la edición de la línea de comandos y el acceso al historial de comandos. ksh tiene el comando fc relativamente limitado (que bash también admite) para su «comando de reparación», es decir, seleccionar elementos de su historial, extraerlos en su editor de texto preferido y ejecutar automáticamente el contenido de ese archivo temporal editado al salir.
Pero bash admite eso y su propio emacs o vi acceso al historial y edición, y el antiguo csh . (bang) operadores también.
bash admite vi edición mode ( set -o vi ) que era, si mal no recuerdo, el predeterminado en ksh 93. Pero bash predeterminado en el modo emacs ( set -o emacs ). Además, por supuesto, también se puede utilizar el comando bash bind para volver a vincular cualquier teclas para cualquiera de una gran cantidad de funciones de edición y manipulación del historial, o en macros que se expanden en cualquier texto que desee poner en una línea de comando.
Además bash tiene muchas variables de entorno «mágicas» que pueden hacer cosas que son casi inimaginablemente sutiles e intrincadas. Por ejemplo, puede configurar la variable PROMPT\_COMMAND para ejecutar un gancho personalizado cada vez que bash a punto de presentar su mensaje. Por lo tanto, podría hacer que verifique algo mágico .dot\_file y volver a personalizar su shell en ejecución según el directorio en el que se encuentre, o restablecer la cadena de mensajes y los colores de la pantalla de la terminal según la hora del día, o consultar algún sitio web y ejecutar automáticamente algún comando basado en … casi cualquier cosa.
(He usado ese gancho para activar automáticamente los entornos virtuales de Python simplemente cambiando a su directorio de trabajo por ejemplo).
Si considera tcsh (o su antepasado, csh ) entonces estás en un nicho. Es común ver scripts de csh en el campo de EDA (automatización de diseño electrónico). Pero eso es un accidente de la historia y la mayoría de las personas que trabajan en ese campo no usan tcsh para su uso interactivo.
La pez la concha también es un nicho. Nunca lo he usado lo suficiente como para formarme una opinión sobre él, y ciertamente es lo suficientemente colorido. Pero creo que va a tener una hilera muy difícil de cavar antes de que cultive un público realmente generalizado. A menos que Apple ™ comience a distribuirlo como el shell predeterminado para sus sistemas Mac ™, probablemente esté condenado a permanecer en su nicho en el futuro previsible.
Así que espero haber dejado claro el punto. Realmente no tiene mucho sentido preguntarse «qué es lo mejor …» (de prácticamente cualquier cosa en la que haya alternativas razonables).
En el caso de los shells de comandos de Unix, las diferencias entre los shells compatibles con Bourne son tan menores que solo los expertos pueden distinguirlos, y esos tienen compensaciones y eventualmente se reducen a preferencias bastante subjetivas. Tengo colegas apasionados por su configuración zsh y otros a quienes simplemente les importa. Estoy en algún punto intermedio de haberme adaptado a la opción más disponible.