Pourquoi -a dans «#! / Bin / sh -a» affecte sed et «set -a» ne fonctionne pas?

Si j'exécute le fichier .sh suivant:

#!/bin/sh -a
echo "a" | sed -e 's/[\d001-\d008]//g'

Le résultat est une erreur:

sed: -e expression # 1, caractère 18: fin de plage non valide

Mais si j'exécute le fichier .sh suivant:

#!/bin/sh
set -a
echo "a" | sed -e 's/[\d001-\d008]//g'

Il s'exécute sans erreur. Le deuxième code n'est-il pas censé être équivalent au premier? Pourquoi l'erreur dans la première?

Lorsque bash est appelé avec le nom sh, il fait ceci :

if (shell_name[0] == 's' && shell_name[1] == 'h' && shell_name[2] == '\0')
    act_like_sh++;

puis définitPOSIXLY_CORRECTy plus tard la variable shell sur :

if (act_like_sh)
  {
    bind_variable ("POSIXLY_CORRECT", "y", 0);
    sv_strict_posix ("POSIXLY_CORRECT");
  }

bind_variableappels bind_variable_internal, qui, si l'attribut shell aest activé à ce moment (ce qui serait le cas si vous appeliez le shell -a), marque la variable shell comme exportée .

Donc dans votre premier script:

#!/bin/sh -a
echo "a" | sed -e 's/[\d001-\d008]//g'

sedest invoqué avec POSIXLY_CORRECT=ydans son environnement, ce qui le fera se plaindre [\d001-\d008]. (La même chose se produit si sed a la --posixpossibilité.)

Dans GNU sed, est un code d'échappement pour le caractère dont la valeur numérique de base 10 est NNN , mais en mode POSIX, cette option est désactivée dans une expression de support, donc , signifie littéralement les personnages , etc., la gamme étant de à . Dans l'ordre des codes de caractères, vient avant (et la plage comprend tous les chiffres sauf zéro, plus toutes les lettres majuscules, plus quelques caractères spéciaux). Dans les paramètres régionaux que vous utilisiez, les tris avant , cependant, de sorte que la plage n'est pas valide.\dNNN[\d001-\d008]\d1\1\en_US.UTF-8\1

Dans votre deuxième script:

#!/bin/sh
set -a
echo "a" | sed -e 's/[\d001-\d008]//g'

même s'il POSIXLY_CORRECTest défini dans le shell, il n'est pas exporté, donc sed est invoqué sans POSIXLY_CORRECTdans l'environnement, et sed s'exécute avec des extensions GNU.

Si vous ajoutez en export POSIXLY_CORRECThaut de votre deuxième script, vous verrez également sed se plaindre.