[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wohin mit den eigenen init-Skripten?



Martin Klaiber <martinkl@zedat.fu-berlin.de> wrote:

> Dazu habe ich auch eine Frage. Man soll laut Doku ja die Variablen
> ENV und BASH_ENV setzen, weil nicht-interaktive shells sonst keine
> startup-files lesen. Ich habe dazu in /etc/environment

>    ENV=~/.profile
>    BASH_ENV=~/.profile

> gesetzt. Bin mir aber unsicher, ob diese relativen Pfadangaben so auch
> verstanden werden. Weiß das jemand?

Ich habe das Ganze jetzt mal getestet und die relativen Pfadangaben
scheinen zu funktionieren. Allerdings wird ENV nicht ausgewertet,
d.h. eine non-interactive /bin/sh läuft mit der locale, die bei der
Installation ausgewählt wurde. BASH_ENV wird ausgewertet, allerdings
arbeitet Debian meines Wissens ja daran, den bash-Aufruf in scripts
soweit wie möglich durch einen einfachen /bin/sh-Aufruf zu ersetzen.

/bin/sh ist bei mir ein link auf /bin/dash und deren manpage macht
keine Angaben zu startup-files für non-interactive shells. Und auch
bei der bash ist mir unklar, ob sie startup-files liest, wenn sie
als sh non-interactive gestartet wird. In der man-page steht dazu:

   A non-interactive shell invoked with the name sh does not attempt
   to read any other startup files.

Ich frage mich, wie "any other" hier gemeint ist. Im Sinne von
"überhaupt keine" oder "keine anderen"? Meinem Sprachempfinden nach
würde ich eher Letzteres annehmen, allerdings macht die man-page in
den restlichen Zeilen nur Angaben zu startup-files für interaktive
shells. Es sieht für mich also bisher so aus, dass sowohl die dash
als auch die bash, wenn sie als sh gestartet wird, im non-interactive
mode überhaupt keine startup-files lesen.

Sollte das so sein, hätte man keine Chance, shell-scripts von /bin/sh
mit LANG=C ausführen zu lassen (solange man es nicht ins script selbst
schreibt), außer man setzt das System global auf LANG=C. Das verblüfft
mich nun doch etwas.

Und wenn ich versuche, mich an meine letzte Debian-Installation zu
erinnern, dann wurde man IIRC auch nur einmal bei der Installation
nach der locale gefragt. Das wird AFAIR im Zuge der Einrichtung der
Tastatur miterledigt.

Nun ist Unix aber ein Mehrbenutzer-System und die einfachen user
könnten theoretisch irgendwo auf dem Erdball sitzen. Erinnert sich
jemand daran, ob Debian beim Anlegen eines normalen Benutzers nochmal
nach der locale fragt? Oder weiß jemand, wie das historisch war?
Liefen die frühen Unix-Systeme auch schon mit einer globalen locale
und die einzelnen user passten das dann für sich individuell an? Das
könnte man heute natürlich auch noch so machen. Dann müsste man die
Tastatur, usw. eben wieder extra konfigurieren. adduser hat ja auch
keine Optionen für locales. Irgendwie war das wohl nie relevant.

Damit rückt dann wieder Michael Welles Sicht in den Fokus, dass man
sich nämlich sagt, wenn das Ganze ein Problem wäre, wäre es sicher
schon jemanden aufgefallen. Denn auch die us-amerikanischen Debian-
Entwickler werden ihr System vermutlich eher mit LANG=en_US als mit
LANG=C installieren, und das sicherlich schon seit Jahren.

Aber so ganz glücklich finde ich das Ganze dennoch nicht, auch wenn es
in der Praxis vielleicht meistens problemlos funktioniert. Denn, und
das vielleicht noch als Beitrag zur Diskussion, ob man zur Bedienung
von Debian Englisch können sollte oder nicht: Zumindest auf der Konsole
und in scripts sind alle Ausgaben ja potenziell auch Eingaben oder
Steueranweisungen für weitere Befehle. Die Ausgaben müssen also nicht
nur vom Benutzer, sondern auch von der Maschine verstanden werden, und
damit müssen die Ausgaben auch Eigenschaften einer Progammiersprache
erfüllen, in erster Linie würde ich hier Eindeutigkeit erwarten. Dieser
Gedanke scheint mir bei den ganzen Lokalisierungsbestrebungen etwas
verloren zu gehen.

Wer vorwiegend graphisch in einer GUI arbeitet, wird das vielleicht
für nicht relevant halten, aber unter der Haube läuft eben immer noch
ein Unix, dessen Funktionalität vermutlich auch bei Desktop-Systemen
immer noch zu einem großen Teil auf scripts basiert. Das soll sich in
Zukunft möglicherweise ändern, systemd scheint mir schon die Richtung
anzudeuten. Dann stellt sich irgendwann aber auch die Frage, welche
Rolle der Unix-Gedanke dann noch für Linux spielt. Aber das wäre eine
andere Diskussion...

Gruß, Martin


Reply to: