Czy powłoki Bash, Bourne i Korn są skompilowane w jednym pliku binarnym w OSX?

7

Jeśli porównasz pliki bash, sh i ksh w OSX 10.8 z kilkoma różnymi opcjami powłoki, mają one ten sam rozmiar. Jeśli pójdziemy dalej i cmppliki binarne, wydaje się, że istnieje tylko jednobajtowa różnica między plikami binarnymi.

To powierzchownie wydaje się wskazywać, że cały kod do obsługi wszystkich różnych powłok jest dostępny w każdym pliku binarnym, ale do którego podzbioru masz dostęp, zależy od tego, którą powłokę wykonasz.

Czy ktoś może potwierdzić, że pliki binarne są w rzeczywistości kompilowane w ten sposób?
Z punktu widzenia Apple, czy ma jakąkolwiek korzyść z połączenia wszystkich powłok w ten sposób?

terminal bash command-line

— nsg
źródło

4

Myślę, że twoje podstawowe założenie jest błędne. Sprawdzanie 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

Technicznie rzecz biorąc, istnieją pewne podobieństwa między shi bash(a później można również zachowywać się tak sh), ale kshostatecznie pochodzą one z innej bazy źródłowej:

— nohillside
źródło

O tak, zdecydowanie masz rację; powinienem patrzeć na cmp -l, a nie tylko na cmp. Dzięki.

— nsg

2

Co ciekawe, / bin / sh tak naprawdę jest bash (chociaż będzie działał w trybie emulacji sh na podstawie nazwy). W niektórych poprzednich wersjach systemu OS X był to twardy link do / bin / bash lub identyczna kopia, ale przynajmniej w 10.8.3 jest nieco inny. Z drugiej strony / bin / ksh jest naprawdę innym programem, który ma mniej więcej taki sam rozmiar.

— Gordon Davisson,

9

ksh i bash są całkowicie różne, ale pliki bash i sh są w większości identyczne. Sh systemu OS X to wersja bash, która:

Ma włączony tryb POSIX . bash domyślnie nie jest zgodny z POSIX.
Ma inne zachowanie podczas uruchamiania. Na przykład sh -lnie czyta ~/.bash_profile/.
Domyślnie włączone xpg_echo. Tak echodziała echo -ei nie obsługuje żadnych opcji.

Domyślny FCEDIT jest edytowany w sh, ale EDITOR lub ed w 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}}"

Źródło można pobrać ze strony http://opensource.apple.com/tarballs/ .

From man bash :

Jeśli bash jest wywoływany z nazwą sh, próbuje naśladować zachowanie startowe historycznych wersji sh tak dokładnie, jak to możliwe, przy jednoczesnym zachowaniu zgodności ze standardem POSIX.

Nie naśladuje jednak innych aspektów oryginalnych pocisków Bourne'a.

Oryginalne powłoki Bourne'a nie są już utrzymywane, a / bin / sh ma być teraz inną powłoką, która jest po prostu zgodna z POSIX. Sh OS OS X pozwala na użycie bashism , które niekoniecznie działają z / bin / sh na innych platformach (takich jak dash na Ubuntu).

— Lri
źródło