Les shells Bash, Bourne et Korn sont-ils compilés en un seul binaire dans OSX?

7

Sur OSX 10.8, si vous comparez les binaires pour bash, sh et ksh, quelques options de shell différentes, elles ont la même taille. Si vous allez plus loin et cmples binaires, il ne semble y avoir qu'une différence d'un seul octet entre les binaires.

Cela semble superficiellement indiquer que tout le code pour prendre en charge tous les différents shells est disponible dans chaque binaire, mais le sous-ensemble auquel vous avez accès dépend du shell que vous finissez par exécuter.

  1. Quelqu'un peut-il confirmer que les fichiers binaires sont en fait compilés de cette façon?
  2. Du point de vue d'Apple, leur avantage est-il de combiner tous les coques de cette manière?
terminal bash command-line NS g
la source

Réponses:

4

Je pense que votre hypothèse de base est fausse. Vérification sur 10.8.3:

pse@Fourecks:~$ ls -l $(type -p sh bash ksh)
-r-xr-xr-x  1 root  wheel  1333920 Oct 16  2012 /bin/bash*
-r-xr-xr-x  1 root  wheel  1380304 Oct 16  2012 /bin/ksh*
-r-xr-xr-x  1 root  wheel  1334000 Oct 16  2012 /bin/sh*
pse@Fourecks:~$ cmp -l $(type -p sh bash) | wc -l
cmp: EOF on /bin/bash
 1138124
pse@Fourecks:~$ cmp -l $(type -p sh ksh) | wc -l
cmp: EOF on /bin/sh
 1238180

Techniquement parlant, il y a quelques similitudes entre shet bash(et le dernier peut également être fait pour se comporter comme sh), mais kshprovient définitivement d'une base de source différente:

nohillside
la source
Oh ouais, tu as définitivement raison; aurait dû regarder cmp -l plutôt que juste cmp. Merci.
nsg
2
Fait intéressant, / bin / sh est en fait bash (bien qu'il s'exécute en mode d'émulation sh en fonction du nom). Dans certaines versions antérieures d'OS X, il s'agissait d'un lien dur vers / bin / bash ou d'une copie identique, mais au moins dans 10.8.3, il est légèrement différent. / bin / ksh, d'autre part, est un programme vraiment différent qui se trouve être à peu près de la même taille.
Gordon Davisson
9

ksh et bash sont complètement différents, mais les binaires bash et sh sont pour la plupart identiques. Sh d'OS X est une version de bash qui:

  • Le mode POSIX est-il activé? bash n'est pas conforme à POSIX par défaut.
  • A un comportement de démarrage différent. Par exemple, sh -lne lit pas ~/.bash_profile/.
  • A xpg_echo activé par défaut. Agit echoainsi echo -eet ne prend en charge aucune option.

Le FCEDIT par défaut est ed in sh mais EDITOR ou ed in bash:

$ diff -y --suppress-common-lines -W 80 <(strings /bin/bash) <(strings /bin/sh)
                                      > /bin/bash
${FCEDIT:-${EDITOR:-ed}}              | ${FCEDIT:-ed}
@(#)PROGRAM:bash  PROJECT:bash-86.1   | @(#)PROGRAM:sh  PROJECT:bash-86.1
$ grep -rF '${FCEDIT:-${EDITOR:-ed}}' ~/Code/Source/bash-86.1/
bash-86.1/bash-3.2/builtins/fc.c:#  define POSIX_FC_EDIT_COMMAND "${FCEDIT:-${EDITOR:-ed}}"
bash-86.1/bash-3.2/builtins/fc.def:#  define POSIX_FC_EDIT_COMMAND "${FCEDIT:-${EDITOR:-ed}}"

La source peut être téléchargée depuis http://opensource.apple.com/tarballs/ .

De l' homme bash :

Si bash est appelé avec le nom sh, il essaie d'imiter le comportement de démarrage des versions historiques de sh aussi fidèlement que possible, tout en se conformant également à la norme POSIX.

Cependant, il n'émule pas d'autres aspects des coques Bourne d'origine.

Les shells Bourne d'origine ne sont plus maintenus, et / bin / sh est maintenant censé être un autre shell qui se conforme simplement à POSIX. Sh d' OS X permet d'utiliser des bashismes qui ne fonctionnent pas nécessairement avec / bin / sh sur d'autres plateformes (comme dash sur Ubuntu).

Lri
la source