> az esetek döntő többségében (ebben egyes kollegák konzervatívabbak) bash-ra állítjuk az eladott gépeken is a root shelljét telepítéskor.
Remélem statikusan linkelt bash-t tesztek oda, mert bizonyos rendszerhibáknál nagyot fogtok szerintem szopni. (*)
Szerintem nem ;-)
Azon helyzetek száma, amikor a /sbin/sh, a /bin/ls meg a /bin/cp működik, de a /bin/bash nem, közelít a nullához - nyilván mesterségesen tudnék ilyen szituációt kreálni, de való életben ez nem életszerű.
Ha pedig nincs ls meg cp, akkor úgyis megette a fene az egészet, nem éri meg erőlködni -> boot cdrom vagy boot net.
> Még nem találkoztam olyan programmal, aminek ezzel gondja lett volna.
Hát a kérdés az, hogy a meg nem nevezett kerjunikszban mi a default: Bourne-shell, vagy Korn-alapú POSIX-shell. Azért van különbség azok és a bash között. guglizd ki a .sig -emet, és mutasd meg azt a bash-verziót, amelyik képes lefuttatni.
/sbin/sh, ami tudásban a ksh tudásának a tört részét sem éri el, valami 1.0-as bourne lesz az...
Nincs pl. PS1 escape-kezelés, ergó nem tudsz olyan promptot csinálni benne, ami megmondja, hogy melyik könyvtárban állsz. A command historyról ne is álmodjunk.
Speciel sose értettem a dolgot: az ember nem loginel root-ként, ha meg su/sudo, akkor azt a plusz exec bash-t mán be tudja gépelni.
Hát, ha _mindig_ beírod, akkor egyszerűbb, ha fixen ez jön be...
Mellesleg, ha ismernéd a bash /etc/profile, /etc/login kezelését, tudnád, hogy ez nehezen kezelhető így. Konkrétabban: oldd meg, hogy a /sbin/sh is emberi promptot írjon ki (pl. ne \u@\h:\w # legyen a prompt), de amikor beindítod a bash-t, abban is jó prompt legyen (legyen benne path). Nem lehetetlen, de küzdős a dolog. Ez persze a bash faszsága, hogy egy nem login shellben nem hajt végre semmilyen központi scriptet, az exec bash meg nem lesz login shell.
Mondjuk ha én lennék a rendszergazda, menne is vissza a /bin/sh.
Nem véletlenül írtam: ahol a rendszergazdának nincs ellenvetése.