Post by Juergen IlsePost by Helmut WaitzmannAn der Datei »"${HOME%/}"/.profile« sollte man überhaupt nichts
unbedacht[1] ändern, denn sie ist /die/ Konfigurationsdatei, an
der der Anwender seine Login‐Umgebung konfiguriert.
Korrekt: seine *LOGIN* Umgebung. Und eine Login-shell ist i.d.R. interaktiv,
die shell, in der ein cron-job ausgefuehrt wird aber i.d.R. nicht.
Ein Login‐Shell ist keinesfalls immer interaktiv. Neben »login«,
das interaktive Shells startet, gibt es auch noch
»su [su-options...] -- - user Shell-Parameters...«,
Logins in grafische Umgebungen, die einen nicht‐interaktiven
Login‐Shell starten, oder eben auch das Bash‐»exec«‐Kommando mit
der Option »-l«.
Post by Juergen IlseDie interaktive Login-shell
hat ein "controlling terminal", die
shell in der der cron-job ausgefuehrt wird dagegen nicht.
Und die Login‐Shells, die auf eine der oben angedeuteten Weisen
gestartet werden, haben auch kein controlling terminal. Das
bedeutet beispielsweise: Wer unbedacht an »"${HOME%/}"/.profile«
Änderungen vornimmt, riskiert, sich nicht mehr grafisch einloggen
zu können, und, wenn's ganz dumm läuft, auch nicht mehr an der
Konsole.
Post by Juergen IlseAll das sind (gerade fuer den nicht so stark in den Feinheiten
drin steckenden User) potentielle Stolperfallen, die zu Problemen
fuehren koennten (weil der User, der seine .profile aendert,
ggfs. die wesentlichen Unterschiede nicht alle in Betracht
gezogen hat).
Ja. Deshalb wäre wirklich jeder Anwender, der seine
Konfigurationsdateien ändern will, gut beraten, sich mit Unix
auszukennen. Und damit ich ausdrücklich nicht nur den Shell: Das
Shell‐Handbuch ist nur für Leser verständlich, die die Grundzüge
von Unix verstehen.
Post by Juergen IlseAuch ist es "ueberraschend" und nicht unbedingt zu erwarten, dass
sich Aenderungen in ${HOME}/.profile auf das Verhalten von
cron-jobs auswirken. Daher sollte man da nichts vermischen, was
nicht zusammengehoert.
Ja. Es ist in etwa so überraschend, wie sich Änderungen auf das
Login am grafischen Anmeldezugang auswirken.
Post by Juergen IlsePost by Helmut WaitzmannDas würde nicht nur bei nicht‐interaktiven Login‐Shells, die man in
Crontabs startet, Ärger machen,
Deswegen tut man das auch nicht.
Post by Helmut Waitzmannsondern bei jedem Login, sei es interaktiv an der Konsole oder?
Deswegen testet man seine Anpassungen an der Datei auch, bevor man sie
als permanente Aenderung im System belaesst.
Vor allen Dingen sollte man nicht nur testen, sondern das Handbuch
lesen und nachdenken.
Post by Juergen IlseUnd diese Datei gehoert aus gutem Grund dem jeweiligen User und
nicht dem Admin: damit der User seine Login-Umgebung an seine
Beduerfnisse anpassen kann. Diese Datei ist dazu da, dass man sie
als User aendern kann.
Exakt.
Post by Juergen IlseSie ist aber nicht dazu da, auch das Environment fuer alle
anderen jobs des Users (z.B. cron-jobs) bereit- zustellen.
Das denkst Du Dir aus. Als prominentes Gegenbeispiel ist mir der
grafische Login‐Zugang begegnet.
Post by Juergen IlsePost by Helmut Waitzmann– je nach System?– auch nicht‐interaktiv am grafischen Zugang.
Ausserdem ist u.U. noch nicht einmal damit wirklich gewaehrleistet,
dass die cron-jobs genauso laufen wie in der interaktiven shell.
Exakt dasselbe gilt für den grafischen Login‐Zugang.
Cron‐Jobs werden sich allein bereits dadurch unterscheiden, dass
sie kein controlling terminal haben. Da muss man die Lage nicht
noch dadurch verkomplizieren, dass man ihnen einen
nicht‐interaktiven Login‐Shell vorenthält.
Post by Juergen IlseEine bash fuehrt in jeder interaktiven shell auch noch
${HOME}/.bashrc aus,
Nein. Login‐Bashs tun das nicht – egal, ob sie interaktiv sind
oder nicht.
Allerdings kann man es hinbekommen, indem man in »~/.bash_profile«
case "$-" in
*i*)
# Die folgenden Kommandos werden nur von einem
# interaktiven Login-Bash ausgefuehrt:
#
# Interaktive Login-Bashs sollen auch
# ~/.bashrc abarbeiten:
#
if test -f ~/.bashrc
then
. ~/.bashrc
fi
;;
*)
# Die folgenden Kommandos werden nur von einem
# nicht-interaktiven Login-Bash ausgefuehrt:
#
;;
esac
reinschreibt.
Das Bash‐Handbuch macht den Vorschlag, in »~/.bash_profile« etwa
if test -f ~/.bashrc
then
. ~/.bashrc
fi
reinzuschreiben. Dann ist es sinnvoll, in »~/.bashrc« zwischen
interaktiven und nicht‐interaktiven Shells zu unterscheiden:
case "$-" in
*i*)
# Die folgenden Kommandos werden nur von einem
# interaktiven Bash ausgefuehrt:
#
;;
*)
# Die folgenden Kommandos werden nur von einem
# nicht-interaktiven Bash ausgefuehrt. Hier empfiehlt es
# sich, nur nach sorgfaeltigster Ueberlegung etwas
# einzutragen, weil nicht-interaktive Shells in der Regel
# Shell-Skripte abarbeiten, und zwar auch solche, die nicht
# vom Aufrufer erstellt wurden:
#
;;
esac
Alle Alias‐ und Funktionsdefinitionen und Variablenbelegungen, die
man nur in interaktiven Shells haben will, kommen dann in den
»interaktiven« Zweig. Dann hat man sie sowohl in interaktiven
Login‐Shells (etwa an der Konsole) als auch in interaktiven
Nicht‐Login‐Shells (etwa im Xterm) zur Verfügung.
Alle Alias‐ und Funktionsdefinitionen, die man nur im
nicht‐interaktiven Fall haben will, kommen in den
»nicht‐interaktiven« Zweig.
Alle Definitionen, die man immer haben will, kommen außerhalb des
»case«‐Kommandos hin.
Definitionen für nicht‐interaktive Shells werden aber eher wenige
sein, weil Shell‐Skripte im Allgemeinen davon ausgehen, eine
POSIX‐Standard‐Umgebung zu haben.
Post by Juergen IlseEine bash fuehrt in jeder interaktiven shell auch noch
${HOME}/.bashrc aus, was in der shell in der der cron-job
ausgefuehrt wird *nicht* der Fall waere (bei ksh haengt das vom
Inhalt der Environment-Variable "ENV" ab), so dass in .bashrc
gesetzte aliases oder shellfunktionen im cron-job nicht zur
Verfuegung stehen.
Ja. Sie stehen nicht zur Verfügung, es sei denn, man sorgt extra
dafür. Und ich empfehle, sehr behutsam dabei vorzugehen,
nicht‐interaktiven Shells selbstausgewählte Aliases oder
Shell‐Funktionen zu verpassen.
Post by Juergen IlsePost by Helmut Waitzmann[1] Auch dafür ist Stackoverflow »gut«: Im von Dir angeführten
<https://stackoverflow.com/questions/2388087/how-to-get-cron-to-call-in-the-correct-paths>
steht ein Verweis auf
<http://stackoverflow.com/q/15557777/1025391>: »Cron job does NOT
get the environment variables set in .bashrc«. Es stellt sich
dann heraus: Die fragliche Zuweisung an die gewünschte Variable
wird wegen
#If not running interactively, don't do anything
[ -z "$PS1" ] && return
am Anfang der Datei nicht ausgeführt, wenn der Shell
nicht‐interaktiv ist.
Standardmaessig wird die .bashrc in nicht interaktiven shells auch nicht
ausgefuehrt. Leider sind einige Distributionen dazu uebergegangen, die
.bashrc auch von anderen Dateien "sourcen" zu lassen und damit die eigent-
lich vorgesehenen Differenzierungen in der bash ausser Kraft zu setzen ...
Post by Helmut WaitzmannDa greift man sich an den Kopf! Kein Wort davon, dass es
vielleicht sinnvoll wäre, zu schauen, welche Kommandos in der
Datei denn nun geeignet sind, sowohl von interaktiven als auch von
nicht‐interaktiven Shells ausgeführt zu werden, und welche nur von
interaktiven Shells ausgeführt werden sollten!
Genau deshalb ist es in der bash vorgesehen, dass .bashrc in interaktiven
shells (und nur in diesen) ausgefuehrt wird.
Nein, das ist es nicht. Aber weil Du das noch immer nicht
verstanden hast, ist auch
Post by Juergen IlseIch habe mich zu Zeiten der "S.u.S.E 4.2" Distribution mit den
SUSE Entwicklern herumgestritten,
kein Wunder.
Post by Juergen Ilseaber die Diskussion ist leider ergebnislos im Sande verlaufen und
SUSE hatte die eigentlich so nicht vorgesehene Konfiguration
Um das im Endeffekt doch noch hinzubekommen, muss man »~/.bashrc«
zumindest im interaktiven Fall aus »~/.bash_profile« heraus
Post by Juergen Ilse(".bashrc" wird, zu- mindest manchmal, auch von ".profile"
gelesen), Andere Distributionen haben sich seitdem leider an
diesen Unfug angepasst.
So ist das halt, wenn man das Handbuch nicht sorgfältig liest:
Dann versteht man die Argumente der anderen nicht und hält sie für
Unfug.
Post by Juergen IlsePost by Helmut WaitzmannVermutung: Die Einschränkung der Kommandos auf interaktive Shells
kam vom Distributor.
... und zwar als workaround fuer den Unfug,
Nein. Aber das wirst Du erst verstehen, wenn Du das Handbuch
gelesen hast. Von
Post by Juergen Ilse.profile und .bashrc sich gegenseitig einlesen zu lassen.
steht im im Handbuch gemachten Vorschlag nichts.
Ob SUSE darüber hinaus noch etwas tut, was nicht nötig wäre, um
alle interaktiven Shells »~/.bashrc« lesen zu lassen, kann ich
nicht beurteilen: Ich habe kein SUSE‐System. Deswegen lass' ich
Post by Juergen IlseBei SUSE spielt da vermutlich auch noch eine Variable
"PROFILE_READ" oder so aehnlich eine Rolle, da sonst der vom
Distributor eingebaute workaround fuer ein vom Distributor verur-
sachte Problem nicht fubnktionieren wuerde ...
Post by Helmut WaitzmannUnd da glaubst Du, ein Anwender, der es nicht rafft, mit
Bedacht Änderungen vorzunehmen, ist in der Lage, seine
Crontab‐Umgebung selbst zusammenzustellen?
Das sollte er koennen (oder von cron die Finger lassen).
Wie gut er es kann, sieht man ja bei Stackoverflow. Oder er fragt
im Usenet, um sich schlau zu machen.
Post by Juergen IlsePost by Helmut WaitzmannPost by Juergen IlseJa. Aber das ist gewollt, da´man beim Verhalten eines cron-jobs nicht
von einem ggfs. nicht von einem ggfs.nicht selbst gesetzten Environment
abhaengig haben moechte ...
Man kann selbst als bedachtsamer Anwender nicht wissen, ob der
Administrator beispielsweise »/usr/xpg4/bin/« in den PATH stellen
muss, damit sein System POSIX‐kompatibel ist. Das weiß nur der
Administrator. Trotzdem möchte man als Anwender
POSIX‐Kompatibilität haben.
Wenn man dem vom Admin vorgesetzten PATH vertraut, aber dennoch eigene
Aenderungen einbringen will, hat sich "PATH=/home/myuser/bin:${PATH}"
oder dergleichen bewaehrt.
Dazu muss »PATH« aber bereits den vom Administrator
bereitgestellten Inhalt haben.
Post by Juergen IlsePost by Helmut WaitzmannPost by Juergen IlseWarum sollte er dass muessen? Genau das Gegenteil ist der Fall. Ein vom
Admin geaendertes /etc/profile kann bei "selbst gesetztem Environment"
keinen Einfluss auf den cron-job haben, und genau das ist es, was man
anstreben sollte. Nur wenn man das Environment selbst setzt, ist man unab-
haengig von ggfs. unangekuendigten Aenderungen vom Admin.
… und fällt auf die Schnauze, wenn so eine Änderung bewirkt, dass
die vom Anwender selbst erstellte Crontab‐Umgebung plötzlich ein
nicht mehr POSIX‐kompatibels System bewirkt.
Deine Argumentation ist doch Unfug. Wie oft hast du es denn schon erlebt,
dass eine vom Admin durchgefuehrte Aenderung einen vormals lauffaehingen
cron-job, der sein eigenes Environment setzt, nicht mehr lauffaehig war?
Weiß ich nicht mehr. Der häufigere Fall war bei mir ein
»ssh«‐Aufruf in einen nicht‐interaktiven Nicht‐Login‐Shell. Der
erhält eine ähnlich unvollständige Umgebung wie ein Cron‐Job. Den
habe ich bald abgestellt, indem ich es hinbekommen habe, »ssh«
einen Login‐Shell starten zu lassen. Ab dann war ein für alle
Male Ruhe im Karton.
Post by Juergen IlsePost by Helmut WaitzmannDu hast vielleicht die folgende Erfahrung nicht gemacht: Ich
hatte schon mit heterogenen Umgebungen zu tun: Dasselbe
HOME‐Verzeichnis wird dem Anwender sowohl von HPUX als auch
Solaris auf verschiedenen Maschinen per NFS zur Verfügung
gestellt. Und natürlich hatte jedes Betriebssystem seine eigene
Belegung der Variablen »PATH«.
... und da erweitert der Anwender das vom Admin bereitgestellte
Environment statt es zu ueberschreiben. Das ist voellig normal.
Dazu muss er es aber erst einmal erhalten (s. o.).
Post by Juergen IlsePost by Helmut WaitzmannPost by Juergen IlsePost by Helmut WaitzmannPost by Juergen Ilseund zum testen das script ggfs. auch mal mit leerem Environment
("env -") aufzurufen ...
Exploits findet man damit nicht?– man erzeugt sie womöglich erst.
???
Ich meine mich zu erinnern, dass mir schon Programme (weiß nicht
mehr, welche) unter die Finger gekommen sind, die eine
Konfigurationsdatei im Verzeichnis (in Shell‐Syntax)
»"${HOME:-.}"/«
verwenden. Wenn nun die Variable »HOME« wegen »env -« nicht
definiert ist…
Das stellt man dann aber beim testen fest,
Nein, das stellt man nicht fest, weil diese Programme sich nicht
beschwert haben, wenn sie eine Konfigurationsdatei von jemand
anderem als Kuckucksei ausbrüten.
Post by Juergen Ilseund kann den Aufruf fuer den Test auf "env - HOME=... ..."
aendern.
Wenn es gut geht, findet man morgen die nächste Umgebungsvariable,
die man noch vergessen hatte. Wie lang machen wir jetzt schon
rum?
Post by Juergen IlsePost by Helmut WaitzmannPost by Juergen Ilse... was aber nichts daran aendert, dass man *reproduzierbares* Verhalten
moechte, und das kann man letztendlich nur gewaehrleisten, wenn man das
relevante Environment *selbst* setzt.
Das war in der oben erwähnten heterogenen Umgebung mit dem von
verschiedenen Betriebssystemen NFS‐montierten gemeinsamen
Home‐Verzeichnis nicht zu machen, ohne auf eine vom Administrator
gewartete Umgebung zurückzugreifen.
Das ist Unsinn.
Oben hattest Du noch vorgeschlagen, PATH zu erweitern, statt
komplett neu zu setzen.
Post by Juergen IlseWenn man dort in einer Umgebung einen cron-job installiert, wird
der selbe cron-job nicht automatisch auf allen Systemen
installiert. Man kann cron-jobs fuer jedes System unabhaengig
installieren, da die User-crontab-Eintraege nicht unterhalb von
$HOME liegen (bei *keinem* System).
Richtig. Deine Wrapper‐Skripte hast Du aber im Home‐Verzeichnis
liegen. Die darfst Du dann für jedes System extra schreiben und
warten. Das tu' ich mir nicht mehr an.
--
Hat man erst verstanden, wie Unix funktioniert, ist auch
das Shell-Handbuch kein Buch mit sieben Siegeln mehr.