expertenaustausch > comp.os.* > comp.os.unix.shell

Andreas M. Kirchwitz (06.02.2011, 19:20)
Hallo Shell-Nutzer!

Die Frage ist so alt wie Unix: Was spricht dagegen, für den
root-Account in /etc/passwd eine andere Shell als die Bourne-Shell
und auch nichts weitgehend Kompatibles zu wählen?

Die alternative Shell soll eine sein, die zum Lieferumfang des
Anbieters gehört. Also nichts Selbstkompiliertes, wo vielleicht
ein erhöhtes Risiko von zerbröselten Library-Abhängigkeiten besteht.
Und die Shell liegt damit im Haupt-Filesystem, womit sie also auch
im Single-User-Modus zur Verfügung stehen sollte.

Google liefert viele Treffer zum Thema.

Die meisten Antworten bestehen im Ratschlag, einen alternativen
Account, beispielsweise "toor", mit der UID/GID 0 einzurichten und
"su - toor" zu verwenden. Oder man solle den Leuten beibringen,
als erstes beispielsweise "exec <lieblingsshell>" einzutippen.
Andere versuchen, in ".profile" für interaktive Logins die
Wunsch-Shell nachzuladen.

Das mag funktionieren, wenn man allein auf einem System arbeitet
oder es mit hochdisziplinierten Hardcore-Sysadmins zu tun hat, aber
in der Praxis tippen die meisten Leute "su", "su -", "sudo" oder
"sudo -i" und wollen dann sofort eine komfortable Shell-Umgebung
vorfinden.

Unter Solaris ist die Standard-root-Shell /sbin/sh, also eine
statische sh. Kann mich allerdings nicht erinnern, dieses Feature
jemals benötigt zu haben. Und solange /usr kein eigenständiges
Filesystem ist, sehe ich ansonsten keinen Nachteil, eine Shell
aus /usr/bin (/bin ist nur ein Link auf /usr/bin) zu verwenden.

Unter Fedora und RedHat ist die Standard-Shell eine dynamisch
gelinkte /bin/bash. Man verschlechtert sich nicht, wenn man
alternativ eine der anderen Shells aus /bin verwendet.

Skripts sollten stets per #! angeben, worunter sie laufen sollen.
Und Linux zeigt mit bash als Standard-Shell, dass 100%ige Bourne-
Shell-Kompatibilität schon lange nicht mehr notwendig ist.

Was spricht also gegen eine andere Shell?

Grüße, Andreas
Sven Mascheck (06.02.2011, 20:43)
Andreas M. Kirchwitz wrote:

[..]
> in der Praxis tippen die meisten Leute "su", "su -", "sudo" oder
> "sudo -i" und wollen dann sofort eine komfortable Shell-Umgebung
> vorfinden.


Ich glaube, das ist ein sehr Usenet-lastiges Thema :)

Im Allgemeinen eine reine Abwägung zwischen "Komfort" und denkbaren
unerwarteten Effekten? Als beliebiges Beispiel: z.B. bei der
Fehlereingrenzung, bei der andere, die man um Unterstützung bittet,
nicht damit rechnen, daß man die Login-Shell von root umgestellt hat?

> Unter Solaris ist die Standard-root-Shell /sbin/sh, also eine
> statische sh.


Nicht mehr seit SunOS 5.10.

> Skripts sollten stets per #! angeben, worunter sie laufen sollen.
> Und Linux zeigt mit bash als Standard-Shell, dass 100%ige Bourne-
> Shell-Kompatibilität schon lange nicht mehr notwendig ist.


1.) #! (also /bin/sh) hat mit der Default Login Shell von "root"
ersteinmal nichts zu tun.

Also ein Themensprung?

2.) Unter Linux hat sich der Anteil der dash als /bin/sh gegenüber bash
in letzter Zeit sogar eher erhöht (Ubuntu 6.10, nun Debian 6.0).

3.) Was bedeutet eigentlich 100% bournekompatibel genau?
(Das sollte schon ganz klar sein, wenn es als Argument auftaucht.)

4.) Nur wenige Systeme haben eine traditionelle Bourne Shell als /bin/sh,
aber es gibt noch welche. Darüberhinaus ist ksh88 bei den kommerziellen
Systemen verbreitet, und allerlei ash-Varianten sowie bash bei den
freien Systemen.
Juergen P. Meier (07.02.2011, 07:24)
Andreas M. Kirchwitz <amk>:
> Hallo Shell-Nutzer!
> Die Frage ist so alt wie Unix: Was spricht dagegen, für den
> root-Account in /etc/passwd eine andere Shell als die Bourne-Shell
> und auch nichts weitgehend Kompatibles zu wählen?


Die Tatsache, dass klassicherweise Cronjobs und andere Systemjobs eine
bourne-kompatible Shell verlangen, und nicht alle und immer ueber
system() gestartet werden (was den hash-bang auswerten wuerde) sondern
auch mal gesourced oder direkt per "$SHELL $SCRIPT" gestartet wurden -
was natuerlich fehl schlaegt, wenn die $SHELL das $SCRIPT nicht
interpretieren kann.

Auch historisch gesehen ist die /bin/sh zumindest im Runlevel S oft
ein statisch gelinktes binary gewesen, also auch bei kaputtem Linker
noch verwendbar (erlaubt das Login des Admins im Fehlerfall, z.B. um
das root-filesystem zu reparieren).

> Die alternative Shell soll eine sein, die zum Lieferumfang des
> Anbieters gehört. Also nichts Selbstkompiliertes, wo vielleicht
> ein erhöhtes Risiko von zerbröselten Library-Abhängigkeiten besteht.
> Und die Shell liegt damit im Haupt-Filesystem, womit sie also auch
> im Single-User-Modus zur Verfügung stehen sollte.


Bei heutigen Desktop-Windows-Emulationen aus dem Linux-Lager gibt es
keine wirklich handfesten Gruende, warum du nicht irgendeine Shell die
Bourne-dialekt beherrscht als Login-Shell fuer den user namens "root"
mit der UID 0 verwenden solltest.
Schliesslich kannst du bei einem defekten /-Fs sowieso nix mehr
ausrichten und musst eh von CD booten. Und der Desktop-User kann ein
System mit defekten ld-loader eh nicht mehr reparieren.

> Google liefert viele Treffer zum Thema.


Ach.

> Die meisten Antworten bestehen im Ratschlag, einen alternativen
> Account, beispielsweise "toor", mit der UID/GID 0 einzurichten und
> "su - toor" zu verwenden. Oder man solle den Leuten beibringen,
> als erstes beispielsweise "exec <lieblingsshell>" einzutippen.
> Andere versuchen, in ".profile" für interaktive Logins die
> Wunsch-Shell nachzuladen.


Ja. Das war dann ueblich - insbesonder bei BSD-Nutzern, die als
user-shell oftmals so Krankheiten wie eine csh nutzten, waehrend
der root-account aus oben genannten Gruenden eine bourne-sh hatte.

> Das mag funktionieren, wenn man allein auf einem System arbeitet
> oder es mit hochdisziplinierten Hardcore-Sysadmins zu tun hat, aber
> in der Praxis tippen die meisten Leute "su", "su -", "sudo" oder
> "sudo -i" und wollen dann sofort eine komfortable Shell-Umgebung
> vorfinden.


Eigentlich nicht.
Und selbst wenn, dann gibts genau dafuer "sudo -s". Wowereit.

> Unter Solaris ist die Standard-root-Shell /sbin/sh, also eine
> statische sh. Kann mich allerdings nicht erinnern, dieses Feature


Eine statisch gelinkte bourne-shell.

> jemals benötigt zu haben. Und solange /usr kein eigenständiges


Ich schon, ich kann mich sogar an zwei Ereignisse erinnern:
Einmal war der soft-raid zerbrochen (beide Spiegelhaelften invalid)
auf dem u.A. /usr lag (dank statischer root-shell konnte ich das
reparieren ohne alles neu machen zu muessen), ein anderes mal
wars ein physischer Festplattendefekt (da konnte ich noch die
wichtigsten Konfig-daten aus /etc sichern um das Neuaufsetzen
nach Plattentausch zu beschleunigen.)

> Filesystem ist, sehe ich ansonsten keinen Nachteil, eine Shell
> aus /usr/bin (/bin ist nur ein Link auf /usr/bin) zu verwenden.


Spaetestens wenn dir ein bad-block deinen ld-loader zerschiesst.

> Unter Fedora und RedHat ist die Standard-Shell eine dynamisch
> gelinkte /bin/bash. Man verschlechtert sich nicht, wenn man


Weil Linux nunmal kein professionelles system ist und statisches
linken mit der beliebten GLIBC in etwa so gut funktioniert wie
stabile Kernfusion zur Energiegewinnung. Ach.

> alternativ eine der anderen Shells aus /bin verwendet.


Richtig erkannt.

> Skripts sollten stets per #! angeben, worunter sie laufen sollen.


Das greift nur wenn sie per system() gestartet werden.

> Und Linux zeigt mit bash als Standard-Shell, dass 100%ige Bourne-
> Shell-Kompatibilität schon lange nicht mehr notwendig ist.


NUR UNTER LINUX, und nur *weil* bei Linux die Shellscript nicht 100%
Bourne-Shell kompatibel sind sondern es sich idR. um Bash-Scripte
handelt!

Fuer andere Unixsysteme gilt dies natuerlich nicht.

> Was spricht also gegen eine andere Shell?


Bei Linux? Nichts. Bei richtigen Unixsystemen hingegen sprechen
teilweise die Betriebsstabilitaetsaspekte dagegen. YMMV.

Juergen
Michael Baeuerle (07.02.2011, 11:24)
"Juergen P. Meier" wrote:
> Andreas M. Kirchwitz wrote:
> Ja. Das war dann ueblich - insbesonder bei BSD-Nutzern, die als
> user-shell oftmals so Krankheiten wie eine csh nutzten, waehrend
> der root-account aus oben genannten Gruenden eine bourne-sh hatte.


Eher anders rum, NetBSD hat doch in der Vergangenheit immer per default
/bin/csh fuer root eingetragen. Das erste was ich dann gemacht habe ist
eine andere Shell zu installieren und die fuer die neu angelegten User
zu verwenden.

Micha
Sven Mascheck (07.02.2011, 11:39)
Juergen P. Meier wrote:

>> Die meisten Antworten bestehen im Ratschlag, einen alternativen
>> Account, beispielsweise "toor", mit der UID/GID 0 einzurichten und
>> "su - toor" zu verwenden. Oder man solle den Leuten beibringen,
>> als erstes beispielsweise "exec <lieblingsshell>" einzutippen.
>> Andere versuchen, in ".profile" für interaktive Logins die
>> Wunsch-Shell nachzuladen.


> Ja. Das war dann ueblich - insbesonder bei BSD-Nutzern, die als
> user-shell oftmals so Krankheiten wie eine csh nutzten, [1]
> waehrend der root-account aus oben genannten Gruenden eine bourne-sh hatte.


Nein, andersrum:

Gerade "root" hatte seit 4.0 BSD /bin/csh als Login Shell.
Das findet sich auch noch auf einigen Nachfolgern
(Net-, FreeBSD bis heute, IRIX bis einschl. 4)
"toor" mit /bin/sh ist deshalb nicht neu, das kam mit 4.3 BSD.

[1]
Grund: es war einfach die erste Shell mit komfortablen Funktionen für
die interaktive Verwendung (v.a. history); sie war nur eben zum Skripten
nicht geeignet. (Unix hat ja leider nie den Sprung geschafft,
line editing und history ins TTY zu integrieren.)
Ähnliche Themen