#! / bin / sh vs #! / bin / bash para máxima portabilidad

Por lo general trabajo con los servidores de Ubuntu LTS, que por lo que entiendo enlace simbólico /bin/sha /bin/dash. Muchas otras distribuciones aunque enlace simbólico /bin/sha /bin/bash.

¿De eso entiendo que si un script usa #!/bin/shen la parte superior, puede no ejecutarse de la misma manera en todos los servidores?

¿Existe una práctica sugerida sobre qué shell usar para los scripts cuando se desea la máxima portabilidad de esos scripts entre servidores?

Hay aproximadamente cuatro niveles de portabilidad para los scripts de shell (en lo que respecta a la línea shebang):

1. Más portátil: use un #!/bin/shshebang y use solo la sintaxis de shell básica especificada en el estándar POSIX . Esto debería funcionar en casi cualquier sistema POSIX / unix / linux. (Bueno, excepto Solaris 10 y versiones anteriores que tenían el shell Bourne heredado real, anterior a POSIX, por lo que no es compatible /bin/sh).

2. La segunda más portátil: use una #!/bin/bash(o #!/usr/bin/env bash) línea shebang y manténgase en las funciones de bash v3. Esto funcionará en cualquier sistema que tenga bash (en la ubicación esperada).

3. Tercero más portátil: use una #!/bin/bash(o #!/usr/bin/env bash) línea shebang y use las funciones de bash v4. Esto fallará en cualquier sistema que tenga bash v3 (por ejemplo, macOS, que tiene que usarlo por razones de licencia).

4. Menos portátil: use un #!/bin/shshebang y use extensiones bash para la sintaxis de shell POSIX. Esto fallará en cualquier sistema que tenga algo más que bash para / bin / sh (como las versiones recientes de Ubuntu). Nunca hagas esto; No es solo un problema de compatibilidad, es simplemente incorrecto. Desafortunadamente, es un error que mucha gente comete.

Mi recomendación: use el más conservador de los primeros tres que proporciona todas las funciones de shell que necesita para el script. Para una portabilidad máxima, use la opción n. ° 1, pero según mi experiencia, algunas funciones bash (como las matrices) son lo suficientemente útiles como para ir con la n. ° 2.

Lo peor que puedes hacer es # 4, usar el shebang incorrecto. Si no está seguro de qué características son POSIX básicas y cuáles son las extensiones bash, quédese con un bash shebang (es decir, opción # 2), o pruebe el script a fondo con un shell muy básico (como el tablero en sus servidores Ubuntu LTS). El wiki de Ubuntu tiene una buena lista de bashisms a tener en cuenta .

Hay una muy buena información sobre el historial y las diferencias entre los shells en la pregunta de Unix y Linux "¿Qué significa ser compatible con sh?" y la pregunta de Stackoverflow "Diferencia entre sh y bash" .

Además, tenga en cuenta que el shell no es lo único que difiere entre los diferentes sistemas; si está acostumbrado a Linux, está acostumbrado a los comandos GNU, que tienen muchas extensiones no estándar que puede no encontrar en otros sistemas Unix (por ejemplo, bsd, macOS). Desafortunadamente, no hay una regla simple aquí, solo tiene que conocer el rango de variación para los comandos que está utilizando.

Uno de los comandos más desagradables en términos de portabilidad es uno de los más básicos: echo. Cada vez que lo use con alguna opción (por ejemplo, echo -no echo -e), o con cualquier escape (barra invertida) en la cadena para imprimir, las diferentes versiones harán diferentes cosas. Cada vez que desee imprimir una cadena sin un salto de línea después de ella, o con escapes en la cadena, use printfen su lugar (y aprenda cómo funciona, es más complicado de lo que echoes). El pscomando también es un desastre .

Otra cosa que hay que observar en general son las extensiones recientes / GNUish para la sintaxis de la opción de comando: el formato de comando antiguo (estándar) es que el comando va seguido de opciones (con un solo guión, y cada opción es una sola letra), seguido de argumentos de comando. Las variantes recientes (y a menudo no portátiles) incluyen opciones largas (generalmente introducidas con --), que permiten que las opciones aparezcan después de los argumentos y que se usan --para separar las opciones de los argumentos.

En el ./configurescript que prepara el lenguaje TXR para construir, escribí el siguiente prólogo para una mejor portabilidad. El script se iniciará incluso si se #!/bin/shtrata de un Bourne Shell antiguo no compatible con POSIX. (Construyo cada versión en una VM Solaris 10).

#!/bin/sh

# use your own variable name instead of txr_shell;
# adjust to taste: search for your favorite shells

if test x$txr_shell = x ; then
  for shell in /bin/bash /usr/bin/bash /usr/xpg4/bin/sh ; do
    if test -x $shell ; then
       txr_shell=$shell
       break
    fi
  done
  if test x$txr_shell = x ; then
    echo "No known POSIX shell found: falling back on /bin/sh, which may not work"
    txr_shell=/bin/sh
  fi
  export txr_shell
  exec $txr_shell $0 ${@+"$@"}
fi

# rest of the script here, executing in upgraded shell

La idea aquí es que encontremos un shell mejor que el que estamos ejecutando, y volver a ejecutar el script usando ese shell. Se establece txr_shellla variable de entorno, de modo que el script ejecutado nuevamente sepa que es la instancia recursiva ejecutada nuevamente.

(En mi secuencia de comandos, la txr_shellvariable también se usa posteriormente, para exactamente dos propósitos: en primer lugar, se imprime como parte de un mensaje informativo en la salida de la secuencia de comandos. En segundo lugar, se instala como la SHELLvariable en el Makefile, por lo que makeutilizará esto shell también para ejecutar recetas).

En un sistema donde /bin/shestá el guión, puede ver que la lógica anterior encontrará /bin/bashy volverá a ejecutar el script con eso.

En un cuadro de Solaris 10, se /usr/xpg4/bin/shactivará si no se encuentra Bash.

El prólogo está escrito en un dialecto de shell conservador, utilizando testpara pruebas de existencia de archivos, y el ${@+"$@"}truco para expandir argumentos que atienden a algunos shells viejos rotos (que simplemente sería "$@"si estuviéramos en un shell conforme POSIX).

Todas las variaciones del lenguaje shell Bourne son objetivamente terribles en comparación con los lenguajes de script modernos como Perl, Python, Ruby, node.js e incluso (posiblemente) Tcl. Si tiene que hacer algo incluso un poco complicado, será más feliz a largo plazo si usa uno de los anteriores en lugar de un script de shell.

La única ventaja que aún tiene el lenguaje shell sobre esos idiomas más nuevos es que se garantiza que algo que se llama a sí mismo /bin/shexiste en todo lo que pretende ser Unix. Sin embargo, ese algo puede no ser compatible con POSIX; muchos de los Unixes propietarios heredados congelaron el lenguaje implementado /bin/shy las utilidades en la RUTA predeterminada antes de los cambios exigidos por Unix95 (sí, Unix95, hace veinte años y contando). Puede haber un conjunto de Unix95, o incluso POSIX.1-2001 si tiene suerte, herramientas en un directorio que no está en la RUTA predeterminada (por ejemplo /usr/xpg4/bin), pero no se garantiza que existan.

Sin embargo, los conceptos básicos de Perl tienen más probabilidades de estar presentes en una instalación de Unix seleccionada arbitrariamente que Bash. (Por "lo básico de Perl" quiero decir que /usr/bin/perlexiste y es una versión, posiblemente bastante antigua, de Perl 5, y si tiene suerte, el conjunto de módulos que se incluyen con esa versión del intérprete también están disponibles).

Por lo tanto:

Si está escribiendo algo que tiene que funcionar en todas partes que pretende ser Unix (como un script de "configuración"), debe usarlo #! /bin/shy no debe usar ninguna extensión. Hoy en día escribiría shell compatible con POSIX.1-2001 en esta circunstancia, pero estaría preparado para parchear POSIXisms si alguien solicitara soporte para hierro oxidado.

Pero si usted está no escribiendo algo que tiene que funcionar en todas partes, entonces el momento en que se ven tentados a utilizar cualquiera del bash en absoluto, usted debe parar y volver a escribir toda la cosa en un mejor lenguaje de script en su lugar. Tu futuro yo te lo agradecerá.

(Entonces, ¿cuándo es apropiado usar extensiones de Bash? Para primer orden: nunca. Para segundo orden: solo para extender el entorno interactivo de Bash, por ejemplo, para proporcionar complementos de pestañas inteligentes y avisos sofisticados).