Ressources pour la programmation shell portable

Quelles ressources existent pour la programmation shell portable? La solution ultime consiste à tester sur toutes les plates-formes ciblées, mais cela est rarement pratique.

La spécification POSIX / Single UNIX est un début, mais elle ne vous indique pas le niveau de prise en charge de chaque implémentation, ni les extensions communes existantes. Vous pouvez lire la documentation de chaque implémentation, mais cela prend beaucoup de temps et n'est pas tout à fait exact.

Il me semble qu'un format idéal serait une sorte de version annotée par la communauté de la spécification POSIX, où chaque fonctionnalité est annotée par son niveau de support parmi les différentes implémentations. Une telle chose existe t elle? Ou existe-t-il d'autres ressources utiles?

_{Par exemple, il y a les pages sur la portabilité du shell de Sven Mascheck , mais elles ne concernent que des éléments syntaxiques et quelques éléments intégrés, et ne couvrent que les anciens shells. Je cherche une ressource plus complète.}

Le manuel autoconf contient une section sur la programmation de shell portable .

Bien que cela ne vise pas spécifiquement POSIX, il s'agit probablement de la collection la plus complète de choses à faire et à ne pas faire lorsque vous essayez d'écrire du code shell portable.

En plus de dashet posh, il y a bournesh(ou bsh), le Heirloom Bourne Shell , qui peut être utilisé pour détecter les Bashism .

Le projet Heirloom inclut également "The Heirloom Toolchest", une collection de plus de 100 utilitaires Unix standard (qui pourraient servir de point de départ pour comparer les options de ligne de commande).

Semblable à cette réponse , essayez d’exécuter votre script en posh .

De plus, n'oubliez pas de définir la POSIXLY_CORRECTvariable d'environnement sur true, car de nombreux programmes (pas uniquement le shell) adhéreront plus strictement aux normes POSIX.

Écrire vos scripts en utilisant dash pourrait être un début.

Dans une certaine mesure, vous pouvez essayer checkbashismsle devscriptspaquet Debian / Ubuntu .

Ce n'est pas parfait, mais cela présente l'avantage d'être un point de départ existant. Par exemple, il ne voit pas les problèmes classiques avec sed/ findconcernant les différences entre GNU et BSD / autres.

Par défaut, il est orienté Debian + tiret, le -pdrapeau peut être utile dans votre cas.

Aujourd'hui, vous pouvez généralement trouver un shell POSIX sur un système, ce qui signifie généralement que vous pouvez utiliser un script en langage POSIX (modulo s'exécutant avec des problèmes de conformité).

Le seul problème est que /bin/shparfois ce n’est pas un shell POSIX. Et vous devez coder en dur la #!ligne dans des scripts qui doivent se comporter comme de beaux exécutables; vous ne pouvez pas simplement demander à l'utilisateur de rechercher le problème, puis d'appeler votre script sous la forme /path/to/posix/shell myscript.

L'astuce consiste donc à utiliser les fonctionnalités POSIX dans votre script, mais à le faire rechercher automatiquement le shell POSIX. Une façon de le faire est comme ça:

#!/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.

Il existe d'autres approches, telles que la génération de code. Boostez vos scripts avec un petit script qui prend un corps de fichiers de script sans #! ligne, et ajoute un.

La pire chose à faire est de commencer à écrire des scripts entiers de manière à ce qu’ils s’exécutent sur un shell Bourne à partir de 1981. Cela n’est nécessaire que si vous devez écrire pour un système qui n’a pas vraiment d’autre shell. .