¿Se recomienda usar zsh en lugar de bash scripts? [cerrado]

¿Puedo suponer que se han zshinstalado suficientes personas para ejecutar scripts con un

#!/usr/bin/env zsh

como shebang?

¿O hará que mis scripts no se puedan ejecutar en demasiados sistemas?

Aclaración: Estoy interesado en programas / scripts que un usuario final quiera ejecutar (como en Ubuntu, Debian, SUSE, Arch & c.)

Para portabilidad, no. Si bien zshse puede compilar en cualquier Unix o similar a Unix e incluso Windows al menos a través de Cygwin, y está empaquetado para la mayoría de los Me gusta de Unix de código abierto y varios comerciales, generalmente no se incluye en la instalación predeterminada.

bashpor otro lado, se instala en sistemas GNU (como bashes el shell del proyecto GNU) como la gran mayoría de los sistemas basados ​​en Linux no integrados y, a veces, en sistemas no GNU como Apple OS / X. En el lado comercial de Unix, el shell Korn (la variante de AT&T, aunque más la ksh88única) es la norma y ambos, bashy zshestán en paquetes opcionales. En los BSD, el intérprete de comandos interactivo preferido es a menudo tcshmientras que shse basa en el Shell de Almquist o pdkshy basho zshnecesidad de ser instalado como paquetes opcionales también.

zshse instala por defecto en Apple OS / X. Incluso solía ser el /bin/shallí. Se puede encontrar por defecto en algunas distribuciones de Linux como SysRescCD, Grml, Gobolinux y probablemente otras, pero no creo que ninguna de las principales.

Por bashejemplo, está la cuestión de la versión instalada y, como consecuencia, las características disponibles. Por ejemplo, no es raro encontrar sistemas con bash3o zsh3. Además, no hay garantía de que el script para el que escribe ahora zsh5funcione, zsh6aunque bashsí intentan mantener la compatibilidad con versiones anteriores.

Para los scripts, mi opinión es: use la sintaxis de shell POSIX ya que todos los Unices tienen al menos un shell llamado sh(no necesariamente en /bin) que puede interpretar esa sintaxis. Entonces no tiene que preocuparse tanto por la portabilidad. Y si esa sintaxis no es suficiente para su necesidad, entonces probablemente necesite más que un shell.

Entonces, sus opciones son:

• Perl, que es omnipresente (aunque de nuevo puede que tenga que limitarse al conjunto de características de las versiones anteriores, y no puede hacer suposiciones sobre los módulos Perl instalados de forma predeterminada)
• Especifique el intérprete y su versión (python 2.6 o superior, zsh 4 o superior, bash 4.2 o superior ...), como una dependencia para su script, ya sea creando un paquete para cada sistema de destino que especifique la dependencia o estipulándolo en un archivo README enviado junto con su script o incrustado como comentarios en la parte superior de su script, o agregando algunas líneas en la sintaxis de Bourne al comienzo de su script que verifica la disponibilidad del intérprete solicitado y rescata con un error explícito cuando no lo es, como este script necesita zsh 4.0 o superior .
• Envíe el intérprete junto con su script (tenga cuidado con las implicaciones de licencia), lo que significa que también necesita un paquete para cada sistema operativo objetivo. Algunos intérpretes lo hacen más fácil al proporcionar una forma de empaquetar el script y su intérprete en un solo ejecutable.
• Escríbelo en un lenguaje compilado. De nuevo, un paquete por sistema de destino.

No, no puedes. Lo que está garantizado disponible es /bin/sh, esencialmente, el shell Bourne original. Casi todas (¡tenga en cuenta "casi"!) Las instalaciones de Linux tendrán bash, pero en los sistemas * BSD es raro (la persuasión BSD tiene dudas graves sobre el código GPL, como bash). No sé cuál es el shell estándar en Mac, pero de nuevo, hay dudas sobre GPL. Lo mismo para Solaris.

zsh es un shell de nicho, no está en la instalación predeterminada de Fedora (y no creo que sea el predeterminado para ninguna distribución importante).

Creo que realmente depende de qué características adicionales de zsh estés usando y dónde. Si planea distribuir su script entre los diferentes usuarios y sistemas, le sugiero que use bash o incluso sh .

Al mismo tiempo, si su script está diseñado para ejecutarse en toda su organización y tiene la convención de tener zsh en sus máquinas (por ejemplo, el mismo AMI básico) y su tarea tiene claros beneficios de extensiones como selectores de archivos avanzados u otras cosas de http: / /www.rayninfo.co.uk/tips/zshtips.html ¡Diría que adelante!

Como se indicó, bashestá comúnmente disponible en la instalación predeterminada para muchas distribuciones. Su script no alcanzará la mayor base de usuarios si confía en zsh.

Una pregunta importante a responder antes de diseñar su script es " ¿Por qué importa en qué shell se ejecuta un script? "

Diferentes shells usan una sintaxis diferente u ofrecen funciones de shell adicionales que pueden no ser compatibles con otros shells. Para escribir una secuencia de comandos para el "mundo general del usuario final de Linux", determine si su secuencia de comandos usa alguna sintaxis o funciones de shell que dependen de un entorno de shell particular.

Por ejemplo, bashshell admite ciertas expansiones que no son compatibles con dashBourne shell o lo que sea que /bin/shapunte al sistema del usuario.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Intenta ejecutar echo {1..10}en /bin/shcomparación con /bin/bashy obtendrás resultados muy diferentes.

Lo mismo ocurre con lo zshque, aunque admite la mayoría de la bashsintaxis, ofrece expansión y sintaxis adicionales que no es compatible con el bashshell. Vea estas tablas comparando shells para ejemplos específicos.

Puede ampliar su base de usuarios potenciales más allá bashal adherirse a los scripts que funcionan cuando se les llama #!/bin/sh -u. Sin embargo, esto da lugar a otra pregunta importante: " ¿Qué se sacrifica a cambio de una mayor portabilidad? "

Determine si las diferencias relacionadas con problemas de seguridad, funcionalidad, eficiencia o cualquier otra cosa que considere una prioridad para su script valdrían la pena. Es posible que no desee el uso generalizado de un script con una vulnerabilidad de seguridad conocida solo porque funciona en más entornos.

Se escriben tantos scripts para bashque el soporte para estos scripts se utilice como criterio al comparar shells de comandos . Muchas más personas podrán ejecutar su script que si se basa en zshcualquier otra sintaxis exclusiva de un entorno de shell.

Además, tenga en cuenta que, en última instancia, no tiene control sobre cómo el usuario ejecuta el script (también es útil para depurar scripts en diferentes shells ):

Recuerde que si usa un shell para leer un script de shell ("sh scriptname"), en lugar de ejecutarlo directamente ("./scriptname"), el shell tratará todos los comentarios al comienzo del shell como comentarios. En particular, se ignorará el comentario que especifica el intérprete que se utilizará al ejecutar el script ("#! / Bin / sh -u"), al igual que todas las opciones enumeradas junto a ese intérprete.

Por lo tanto, lo mejor que puede hacer al respecto es hacer que sus scripts sean portátiles, siempre que no haya un gran sacrificio en su funcionamiento.

También puede ver convenciones de codificación Bash: desbordamiento de pila .

Lo único que casi puede garantizar es que hay un /bin/sh. Eso podría ser un shell vinculado realmente estático, o puede ser un enlace a otro shell. Ese otro shell generalmente detecta que se llama sh y se ejecutará en modo de compatibilidad.

Observe el casi en la primera oración.

Cada sistema similar a Unix en el que trabajé lo tenía. Muchos de ellos también tenían instalado bash (pero no todos . Por ejemplo, bash no está instalado por defecto en algunos BSD. Algunas distribuciones de Linux se envían con DASH , el shell Debian Almquist en su lugar.

Lo que puede garantizar son sus instrucciones de instalación. Puede agregar una línea al archivo README que indique que necesita zsh. Si crea un paquete, puede marcar zsh como una dependencia. Puede verificarlo con las herramientas autoconf / automake. Puede comprobar si se encuentra zsh en el script de instalación (comience con / bin / sh e intente localizar zsh, si se encuentra, continúe. Si no se muestra un error, por ejemplo, "Advertencia: ZSH no está instalado. ¡Lea el archivo de instrucciones de instalación! ".)

Estoy seguro de que olvidé algunas opciones más. Pero los puntos clave son:

• No puede garantizar nada hasta que lo haya verificado.
• Está casi garantizado que / bin / sh está presente, y que puede hacer algunas comprobaciones con eso.