Existe-t-il un code sh qui n'est pas un code bash syntaxiquement valide?

Y a-t-il un shcode qui n'est pas du code bash syntaxiquement valide (ne barf sur la syntaxe)?

Je pense à écraser shavec bashpour certaines commandes.

bash shell-script posix

— Alexander Mills
source

Je suppose que par valide, je voulais dire syntaxiquement valide, donc ça ne va pas à l'encontre de la syntaxe

— Alexander Mills

Une tokenisation différente? par exemple ((vient à l'esprit.

— 2018

Pour certaines distributions, /usr/bin/shc'est juste un lien symbolique vers /usr/bin/bash(j'utilise CentOS 7.3 et c'est le cas). Vous devriez vérifier si shc'est vraiment bashpour votre distribution.

— Centimane

Il y a quelques années, tout mon projet s'est cassé quand quelque chose a été "mis à jour" dans bash. J'ai dû changer toutes mes lignes de shebang de #!/bin/shà #!/bin/bash. Ensuite, tout a fonctionné à nouveau, vous devez donc être très prudent. Cela est peut-être arrivé lorsqu'ils ont commencé à utiliser dash au lieu de bash pour sh.

— Joe

@Joe, c'est l'opposé de ce que l'OP demande - vous aviez du code bash qui était mal étiqueté comme étant du code sh mais ne l'était pas. L'OP demande s'ils peuvent avoir du code sh (réel, non mal étiqueté) qui casse quand il s'exécute avec bash, pas s'ils peuvent avoir du code bash qui casse quand il s'exécute avec sh (ce qui est évident - si les extensions bash n'ont pas n’ont aucun effet sur les fonctionnalités linguistiques disponibles, il ne s’agit pas d’extensions).

— Charles Duffy

Réponses:

Voici du code qui fait quelque chose de différent dans POSIX sh et Bash:

hello &> world

Que ce soit "invalide" pour vous, je ne sais pas.

Dans Bash, il réoriente à la fois la sortie standard et l' erreur standard de hellodans le fichier world. Dans POSIX sh, il s'exécute helloen arrière-plan puis effectue une redirection vide dans world, la tronquant (c'est-à-dire qu'il est traité comme & >).

Il existe de nombreux autres cas où les extensions Bash feront leur travail lorsqu'elles seront exécutées sous bash, et auraient des effets différents dans un POSIX pur sh. Par exemple, l' expansion des accolades en est une autre, et elle fonctionne également de la même manière en mode POSIX de Bash et non.

En ce qui concerne les erreurs de syntaxe statiques, Bash a à la fois des mots réservés (comme [[et time) non spécifiés par POSIX, tels que du [[ xcode shell POSIX valide mais une erreur de syntaxe Bash, et un historique de divers bogues d'incompatibilité POSIX qui peuvent entraîner des erreurs de syntaxe, comme celui de cette question :

x=$(cat <<'EOF'
`
EOF
)
bash: line 2: unexpected EOF while looking for matching ``'
bash: line 5: syntax error: unexpected end of file

Syntax-errors-only est une définition assez dangereuse de "invalide" dans toutes les circonstances où cela est important, mais il est là.

— Michael Homer
source

Notez que bien que l'expansion d'accolade rend actuellement bash (et zsh, pdksh, ksh93) non conforme, POSIX travaille à l'ajout de dispositions dans la spécification pour permettre l'expansion d'accolade (et {fd}>fileun problème similaire), afin que bash puisse être à nouveau conforme (expansion d'accolade resterait non spécifié, mais des scripts conformes devraient faire echo "{a,b}"s'ils veulent {a,b}être sortis). Voir la discussion qui a commencé

— Stéphane Chazelas

Également pertinent pour cette Q&R: austingroupbugs.net/view.php?id=1191#c3983

— Stéphane Chazelas

Est-ce que quelqu'un qui écrit un script dans POSIX sh pourrait écrire une commande comme celle-ci? L'OP va de sh à bash, et d'après ma compréhension, cela semble être plus un problème dans l'autre sens?

— Rich

@ Rich: Bien sûr. Je n'utilise aucun système où /bin/shest bash, donc si je n'étais pas activement au courant de ce bashisme, en écrivant une ligne de commande, cela pourrait facilement arriver. L'espacement dans la réponse le rend peu probable, mais hello&>worldest moins tiré par les cheveux.

— R ..

J'ai vu un bug à cause de la &>différence le mois dernier!

— Gordon Davisson

Un petit exemple:

time()(:)

timedans Bash est un mot réservé et se comporte différemment du timeprogramme. Il est fort probable que vous cassiez certains scripts pratiques en essayant d'analyser le résultat timeen utilisant bash. Mais techniquement, ce n'est pas une erreur de syntaxe. La redéfinition en timetant que fonction serait rare mais provoque une erreur de syntaxe comme cette question le spécifie.

Un exemple plus court:

a():

Valide dans dash, mais pas compatible POSIX.

— user23013
source

Plus généralement, tout mot qui est un mot-clé non standard ou une commande intégrée dans Bash provoquera le même effet. En plus time, il y a des choses comme declare, function, selectet coproc. Bien que certains d'entre eux soient explicitement marqués comme non spécifiés dans la norme ( mots - clés et prédéfinis / utilitaires ), mais je ne peux pas voir par exemple timeou coprocdans la liste. Et l'utilisation --posixne semble pas aider.

— ilkkachu