Pourquoi sh -c 'echo -n 1' est différent de bash -c 'echo -n 1'

Je suis sur un Mac Book Air, OSX 10.8.

J'essaie de comprendre pourquoi ces deux fragments n'impriment pas la même sortie. sh -c 'echo -n 1' sorties -n 1 alors que bash -c 'echo -n 1' produit 1 comme prévu.

Pourriez-vous m'aider à expliquer pourquoi et comment les faire sortir (si possible)?

Parce qu'apparemment Mac OS est l'un des systèmes qui répond à l'option xpg_echo lorsqu'il est exécuté en mode POSIX. Exécuter bash en tant que / bin / sh équivaut à s'exécuter avec --posix ou en définissant POSIXLY_CORRECT.

La solution consiste à cesser d'utiliser l' echo sauf dans les cas où il ne peut y avoir aucune ambiguïté. printf est le rlocation portable. N'utilisez jamais les indicateurs d'option pour écho, (et utilisez printf si vous le faites).

Il existe plusieurs implémentations historiques incompatibles de l' echo qui brisent sa spécification d'une manière qui ne peut pas être corrigée, et les options sont donc non portables. Je ne suis au courant de rien qui implémente actuellement l' echo POSIX correctement.

shopt -u xpg_echo devrait modifier ce comportement. Aussi comme vous l'avez déjà découvert, ne pas s'exécuter en mode POSIX.

Aussi, vous pouvez mettre à jour … bash 3 devient un peu croustillant. De nombreux bugs ont été corrigés depuis.

/bin/sh est en fait une version de bash qui démarre en mode POSIX ( bash --posix ) et a aussi d'autres changements. Une autre différence est qu'elle interprète les séquences d'échappement par défaut:

 $ bash -c "echo 'a\ba'" a\ba $ sh -c "echo 'a\ba'" a $ sh -c "shopt -u xpg_echo; echo 'a\ba'" a\ba $ bash --posix -c "echo 'a\ba'" a\ba 

printf %s fonctionnerait de la même façon dans la plupart des environnements.

Vous pouvez aussi écrire des scripts pour bash. Le sh d'OS X ne vous empêche pas d'utiliser des Bashisms qui pourraient ne pas fonctionner avec /bin/sh sur d'autres plateforms, comme dash sur Ubuntu.

Voir aussi cette question et la section sur l'écho sur ce site .