Recursos para la programación de shell portátil

¿Qué recursos existen para la programación de shell portátil? La respuesta final es probar en todas las plataformas específicas, pero eso rara vez es práctico.

La especificación POSIX / Single UNIX es un comienzo, pero no le dice cuál es el nivel de soporte de cada implementación ni qué extensiones comunes existen. Puede leer la documentación de cada implementación, pero eso lleva mucho tiempo y no es completamente preciso.

Me parece que un formato ideal sería algún tipo de versión anotada por la comunidad de la especificación POSIX, donde cada característica está anotada por su nivel de soporte entre las diferentes implementaciones. ¿Hay tal cosa? ¿O hay otros recursos útiles?

_{Por ejemplo, hay páginas de portabilidad de shell de Sven Mascheck , pero solo se trata de elementos sintácticos y algunos elementos incorporados, y solo cubre shells antiguos. Estoy buscando un recurso más completo.}

El manual de autoconf tiene una sección sobre programación de shell portátil .

Aunque eso no está dirigido específicamente a POSIX, es probablemente la colección más completa de qué hacer y qué no hacer al intentar escribir código shell portátil.

Además de dashy posh, hay bournesh(o bsh), Heirloom Bourne Shell , que se puede usar para detectar Bashisms .

The Heirloom Project también incluye "The Heirloom Toolchest", una colección de más de 100 utilidades estándar de Unix (que podría servir como punto de partida para comparar las opciones de la línea de comandos).

Similar a esta respuesta , intente ejecutar su script en elegante .

Además, no olvide establecer la POSIXLY_CORRECTvariable de entorno en true, ya que esto hace que muchos programas (no solo el shell) se adhieran más estrictamente a los estándares POSIX.

Escribir sus scripts usando guión podría ser un comienzo.

Hasta cierto punto, puede probar checkbashismsen el devscriptspaquete Debian / Ubuntu .

No es perfecto, pero tiene el beneficio de ser un punto de partida existente. Por ejemplo, no ve las fallas clásicas con sed/ con findrespecto a GNU vs BSD / otras diferencias.

Por defecto, está orientado a Debian + dash, el -pindicador puede ser útil en su caso.

Hoy en día, generalmente puede encontrar un shell POSIX en un sistema, y ​​eso generalmente significa que puede escribir en el lenguaje POSIX (módulo con errores de cumplimiento).

El único problema es que a /bin/shveces no es un shell POSIX. Y debe codificar la #!línea en scripts que se comporten como buenos ejecutables; no puede simplemente pedirle al usuario que investigue el problema y luego invoque su script como /path/to/posix/shell myscript.

Por lo tanto, el truco es utilizar las funciones POSIX en su script, pero hacer que el script encuentre automáticamente el shell POSIX. Una forma de hacerlo es así:

#!/bin/sh

# At this point, we may be running under some old shell
# we have to tread carefully.

# note how we use test rather than [ ] syntax and avoid
# depending on test with no argument producing a failure;
# i.e. "test $posix_shell".

if ! test x$posix_shell = x ; then
  # the three possible shell paths are just an example;
  # please extend as necessary.

  for shell in /usr/xpg4/bin/sh /bin/bash /usr/bin/bash ; do
    if test -x $shell ; then
       posix_shell=$shell
    fi
  done
  if test x$posix_shell = x ; then
    echo "no POSIX shell found"
    exit 1
    # or we could avoid bailing here and just fall back on /bin/sh:
    # echo "falling back on /bin/sh: cross your fingers that it works"
    # posix_shell=/bin/sh
  fi
  export posix_shell

  # plain "$@" is broken in ancient shells! 
  # I seem to recall ${@+"$@"}: not sure if that's the right trick.

  exec $posix_shell $0 ${@+"$@"}  # can we count on exec in legacy shells? 
fi

# phew, at this point in the script we have been re-executed and are
# being interpreted by some reasonably modern shell. We can use $(...)
# command substitution, and other features.

Existen otros enfoques, como la generación de código. Boostrap sus scripts con un pequeño script que toma un cuerpo de archivos de script sin un # línea, y agrega uno.

Lo peor que puede hacer es comenzar a escribir scripts completos de tal manera que se ejecuten en un shell Bourne desde 1981. Esto solo es necesario si debe escribir para un sistema que realmente no tiene ningún otro shell .