Wo in Debian global $PATH setzen

[Matthias Taube]

Wo kann ich in Debian global $PATH setzen?


Ich mï¿œchte /media/data/scripte in den fï¿œr alle shell in den Path aufnehmen.

Wenn ich dieses in /etc/profile an den Path anfï¿œge, steht diese Umgebung
bei einem Login auf der Kommandozeile zur Verfï¿œgung. In einem
Terminalfenster unter xfce ist dies jedoch nicht dem Pfad angefï¿œgt.

Auch ein link im Homeverzeichnis von $HOME/bin auf diesen Pfad hat
nichts gebracht.

Je nachdem, wie ich das Terminal unter der grafischen Oberflï¿œche starte,
zeigt mir ps auxfww folgende Hierarchie an:

/usr/bin/x-terminal-emulator
\_ /bin/bash

bzw:
> \_ lightdm --session-child 12 19
> \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
> \_ xfce4-session
> \_ xfce4-panel --display :0.0 --sm-client-id 279a70bff-7e2c-467e-8605-a4f8026c0a18
> | \_ xfce4-terminal
> | \_ bash

mfg
Matthias


--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/kcc7g4$p89$1...@ger.gmane.org

[Kai-Martin Knaak]

Matthias Taube wrote:

> In einem

> Terminalfenster unter xfce ist dies jedoch nicht dem Pfad angefügt.
>

Wird vielleicht bei Dir in $HOME/.bashrc oder In $HOME/.profile die
Pfad-Variable so gesetzt, das der in /etc/profile definiere Wert nicht
ergännzt, sondern überschreiben wird?

---<)kaiamrtin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53

--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/kcc87h$vdp$1...@ger.gmane.org

[Matthias Taube]

Am 06.01.2013 17:20, schrieb Kai-Martin Knaak:
> Wird vielleicht bei Dir in $HOME/.bashrc oder In $HOME/.profile die
> Pfad-Variable so gesetzt, das der in /etc/profile definiere Wert nicht
> ergännzt, sondern überschreiben wird?

Nein, beide Dateien sind auf den Standardwerten nach der Installation,
d.h. in $HOME/.bashrc wird PATH nicht angefasst und in $HOME/.profile
gibt es nur die standardmäßige

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi


Dies wird für eine Login-Shell auf der Kommandozeile ausgeführt, aber
leider nicht für Shells die aus der grafischen Umgebung heraus gestartet
werden.

mfg
Matthias

--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/kcc9ii$ah0$1...@ger.gmane.org

[Sascha Reißner]

Am Sonntag, den 06.01.2013, 17:07 +0100 schrieb Matthias Taube:
> Wo kann ich in Debian global $PATH setzen?
>
>

> Ich möchte /media/data/scripte in den für alle shell in den Path aufnehmen.
>
> Wenn ich dieses in /etc/profile an den Path anfüge, steht diese Umgebung
> bei einem Login auf der Kommandozeile zur Verfügung. In einem
> Terminalfenster unter xfce ist dies jedoch nicht dem Pfad angefügt.

Weil das Terminal keine Login-Shell ist.
Geh im Terminal mal auf 'Bearbeiten' -> 'Profileinstellungen' und dort
auf den Reiter 'Titel und Befehl'.
Dort setzt du den Haken bei 'Befehl als Login-Shell starten'.
Öffne ein neues Terminal und kontrolliere mit 'echo $PATH'.
Dein Pfad sollte nun dabei sein.

--
mfG Sascha

Herr Ober, meine Suppe ist kalt!
Kein Wunder, die haben sie ja auch schon vor einer Stunde bestellt.

[Matthias Taube]

Am 06.01.2013 18:28, schrieb Sascha Reißner:

> Weil das Terminal keine Login-Shell ist.
> Geh im Terminal mal auf 'Bearbeiten' -> 'Profileinstellungen' und dort
> auf den Reiter 'Titel und Befehl'.

Perfekt, danke.

In meinem Terminal (Konsole von KDE) ist zwar dieser Menübefehl nicht
vorhanden, man kann aber in den Einstellung dem Kommando /bin/bash die
Option -l mit übergeben.

Damit läuft alles so wie es sein soll. Vielen Dank.

mfg
Matthias


--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/kccecd$iir$1...@ger.gmane.org

[Martin Steigerwald]

Am Sonntag, 6. Januar 2013 schrieb Sascha Reißner:
> Am Sonntag, den 06.01.2013, 17:07 +0100 schrieb Matthias Taube:
> > Wo kann ich in Debian global $PATH setzen?
> >
> >
> > Ich möchte /media/data/scripte in den für alle shell in den Path
> > aufnehmen.
> >
> > Wenn ich dieses in /etc/profile an den Path anfüge, steht diese Umgebung
> > bei einem Login auf der Kommandozeile zur Verfügung. In einem
> > Terminalfenster unter xfce ist dies jedoch nicht dem Pfad angefügt.
>
> Weil das Terminal keine Login-Shell ist.
> Geh im Terminal mal auf 'Bearbeiten' -> 'Profileinstellungen' und dort
> auf den Reiter 'Titel und Befehl'.
> Dort setzt du den Haken bei 'Befehl als Login-Shell starten'.
> Öffne ein neues Terminal und kontrolliere mit 'echo $PATH'.
> Dein Pfad sollte nun dabei sein.

Alternativ halt dann doch Shell-Spezifisch in:

/etc/bash.bashrc

/etc/zshrc oder besser /etc/zshenv


Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische Konfigurationsdateien. Könnte also sein, dass es so oder so shell-spezifisch ist, und dann würde ich die rc/env-Dateien bevorzugen, damit es auch für Nicht-Login-Shells passt.


Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber binden die anderen Dateien gar nicht ein:

martin@merkaba:/etc#1> grep environment bash.bashrc
martin@merkaba:/etc#1> grep environment profile
martin@merkaba:/etc#1> grep environment zsh/zshrc
martin@merkaba:/etc#1> grep environment zsh/zshenv
# search path, plus other important environment variables.
martin@merkaba:/etc>

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/201301071317...@lichtvoll.de

[Heiko Schlittermann]

Martin Steigerwald <Mar...@lichtvoll.de> (Mo 07 Jan 2013 13:17:34 CET):

> Alternativ halt dann doch Shell-Spezifisch in:
> /etc/bash.bashrc

In den rc-Files hat das eigentlich nichts zu suchen, meine ich.
Umgebungsvariablen werden vererbt, müssen also nur rechtzeitig gesetzt
werden. Die rc-Files werden bei jeder interaktiven Shell gelesen, wenn
sie keine Login-Shell ist.

Die Shell im Terminal zu einer Login-Shell zu machen, ist eine gute
Sache, der neue PATH gilt dann aber eben nur für Kinder von Prozessen im
Terminal (und natürlich die Shell im Terminal selbst.

Wenn Du es in der gesamten X-Umgebung brauchst, solltest Du es in einem der
Scripte der XSession unterbringen.

> Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische Konfigurationsdateien. Könnte also sein, dass es so oder so shell-spezifisch ist, und dann würde ich die rc/env-Dateien bevorzugen, damit es auch für Nicht-Login-Shells passt.

Nicht-Login-Shells sind eigentlich immer (mehr oder weniger direkte) Kinder
von Login-Shells und sollten die Umgebung geerbt haben.

> Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber binden die anderen Dateien gar nicht ein:
>
> martin@merkaba:/etc#1> grep environment bash.bashrc
> martin@merkaba:/etc#1> grep environment profile
> martin@merkaba:/etc#1> grep environment zsh/zshrc
> martin@merkaba:/etc#1> grep environment zsh/zshenv
> # search path, plus other important environment variables.

/etc/environment, diese Datei müsste von pam_env.so gelesen werden und
da jeder Deiner Arbeiten wahrscheinlich ein Login vorausgeht, und damit
auch ein Interaktion mit PAM, sollte das klappen. Dann ist das auch
unabhängig davon, ob Deine Shell sich nun für /etc/profile interessiert.


M.E. ist /etc/environment der wirklich korrekte Weg.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-

[Dietz Pröpper]

Martin Steigerwald:

> Am Sonntag, 6. Januar 2013 schrieb Sascha Reißner:
> > Am Sonntag, den 06.01.2013, 17:07 +0100 schrieb Matthias Taube:
> > > Wo kann ich in Debian global $PATH setzen?
> > >
> > >
> > > Ich möchte /media/data/scripte in den für alle shell in den Path
> > > aufnehmen.
> > >
> > > Wenn ich dieses in /etc/profile an den Path anfüge, steht diese
> > > Umgebung bei einem Login auf der Kommandozeile zur Verfügung. In
> > > einem Terminalfenster unter xfce ist dies jedoch nicht dem Pfad
> > > angefügt.
> >
> > Weil das Terminal keine Login-Shell ist.
> > Geh im Terminal mal auf 'Bearbeiten' -> 'Profileinstellungen' und dort
> > auf den Reiter 'Titel und Befehl'.
> > Dort setzt du den Haken bei 'Befehl als Login-Shell starten'.
> > Öffne ein neues Terminal und kontrolliere mit 'echo $PATH'.
> > Dein Pfad sollte nun dabei sein.
>
> Alternativ halt dann doch Shell-Spezifisch in:
>
> /etc/bash.bashrc
>
> /etc/zshrc oder besser /etc/zshenv

Das hat halt den Nachteil, dass man es an x Stellen pflegen muss.

> Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist
> mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische
> Konfigurationsdateien. Könnte also sein, dass es so oder so
> shell-spezifisch ist, und dann würde ich die rc/env-Dateien bevorzugen,
> damit es auch für Nicht-Login-Shells passt.
>
>
> Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber
> binden die anderen Dateien gar nicht ein:
>
> martin@merkaba:/etc#1> grep environment bash.bashrc
> martin@merkaba:/etc#1> grep environment profile
> martin@merkaba:/etc#1> grep environment zsh/zshrc
> martin@merkaba:/etc#1> grep environment zsh/zshenv
> # search path, plus other important environment variables.
> martin@merkaba:/etc>

/etc/environment wird via pam ausgewertet, und funktioniert wie erwartet.
Ob's für Shells so geht wage ich zu bezweifeln, spätestens wenn
/etc/profile ausgeführt wird ist der PATH weg (da in /e/p explitit gesetzt)

Hier funktioniert auch ein Eintrag in /etc/profile, das liegt vermutlich
dran, dass ich kde verwende, startkde /bin/sh shebang't und /bin/sh ein
symlink auf dash ist. So wie ich die dash-Manpage verstehe, geht die dash,
wenn stdin nicht auf ein Terminal zeigt (was bei startkde halten dürfte,
/proc/<pid>/fd bestätigt dies), von einer Loginshell aus, und wertet
/etc/profile aus.

Irgendwann war das mal einfacher :-).

[Martin Steigerwald]

Am Montag, 7. Januar 2013 schrieb Heiko Schlittermann:
> Martin Steigerwald <Mar...@lichtvoll.de> (Mo 07 Jan 2013 13:17:34 CET):
> > Alternativ halt dann doch Shell-Spezifisch in:
> > /etc/bash.bashrc
>
> In den rc-Files hat das eigentlich nichts zu suchen, meine ich.
> Umgebungsvariablen werden vererbt, müssen also nur rechtzeitig gesetzt
> werden. Die rc-Files werden bei jeder interaktiven Shell gelesen, wenn
> sie keine Login-Shell ist.

Hmmm, ja. Und selbst wenn sie eine ist:

martin@merkaba:~> grep bashrc .bash_profile
# include .bashrc if it exists
#if [ -f ~/.bashrc ]; then
# source ~/.bashrc
if [ -e ~/.bashrc ]
# execute .bashrc if it exists.
. ~/.bashrc
martin@merkaba:~> grep bashrc /etc/profile
# The file bash.bashrc already sets the default PS1.
if [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc

Nun, PATH ist in /etc/profile definiert und nicht in der /etc/bash.bashrc,
also scheint Upstream Deine Meinung zu teilen.

> Die Shell im Terminal zu einer Login-Shell zu machen, ist eine gute
> Sache, der neue PATH gilt dann aber eben nur für Kinder von Prozessen im
> Terminal (und natürlich die Shell im Terminal selbst.

Warum? De facto ist sie doch keine. Ich habe mich nicht extra mit für die
Shell anmelden müssen.

> Wenn Du es in der gesamten X-Umgebung brauchst, solltest Du es in einem
> der Scripte der XSession unterbringen.

Ich hab Pfad-Anpassungen für mich persönlich einfach in der ~/.zshrc

Ja, ist vielleicht auch nicht der optimale Ort, doch ich bin da irgendwann
ausgestiegen bei der verschachtelten Logik, wer da was wann einbindet.

> > Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist
> > mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische
> > Konfigurationsdateien. Könnte also sein, dass es so oder so
> > shell-spezifisch ist, und dann würde ich die rc/env-Dateien
> > bevorzugen, damit es auch für Nicht-Login-Shells passt.
>
> Nicht-Login-Shells sind eigentlich immer (mehr oder weniger direkte)
> Kinder von Login-Shells und sollten die Umgebung geerbt haben.

Demnach müsste der Pfad aber auch in X11 gesetzt sein. Zumindest eine KDE-
Sitzung wird über ein Shell-Skript hochgefahren. Und auch mit anderen Setups
dürften Shell-Skripte die Hauptrolle spielen. Bei Matthias hat aber
irgendetwas diese Vererbungslogik unterbrochen.

> > Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber
> > binden die anderen Dateien gar nicht ein:
> >
> > martin@merkaba:/etc#1> grep environment bash.bashrc
> > martin@merkaba:/etc#1> grep environment profile
> > martin@merkaba:/etc#1> grep environment zsh/zshrc
> > martin@merkaba:/etc#1> grep environment zsh/zshenv
> > # search path, plus other important environment variables.
>
> /etc/environment, diese Datei müsste von pam_env.so gelesen werden und
> da jeder Deiner Arbeiten wahrscheinlich ein Login vorausgeht, und damit
> auch ein Interaktion mit PAM, sollte das klappen. Dann ist das auch
> unabhängig davon, ob Deine Shell sich nun für /etc/profile interessiert.
>
>
> M.E. ist /etc/environment der wirklich korrekte Weg.

Hehe, korrekt oder nicht :). Ich erinnere mich noch gut an den umask-Bug-
Report, wo es darum ging, wie man diese am besten global setzt. Mein
aktueller Stand und das funktioniert auf der Arbeit tatsächlich so, ist
pam_umask.


Jow, man pam_env:

FILES
/etc/security/pam_env.conf
Default configuration file

/etc/environment
Default environment file

$HOME/.pam_environment
User specific environment file

Das kann Matthias ja dann mal ausprobieren.

Ciao,

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/201301071402...@lichtvoll.de

[Martin Steigerwald]

Am Montag, 7. Januar 2013 schrieb Dietz Pröpper:
[…]

> > Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber
> >
> > binden die anderen Dateien gar nicht ein:
> >
> >
> > martin@merkaba:/etc#1> grep environment bash.bashrc
> > martin@merkaba:/etc#1> grep environment profile
> > martin@merkaba:/etc#1> grep environment zsh/zshrc
> > martin@merkaba:/etc#1> grep environment zsh/zshenv
> > # search path, plus other important environment variables.
> > martin@merkaba:/etc>
>
> /etc/environment wird via pam ausgewertet, und funktioniert wie erwartet.
> Ob's für Shells so geht wage ich zu bezweifeln, spätestens wenn
> /etc/profile ausgeführt wird ist der PATH weg (da in /e/p explitit
> gesetzt)
>
> Hier funktioniert auch ein Eintrag in /etc/profile, das liegt vermutlich
> dran, dass ich kde verwende, startkde /bin/sh shebang't und /bin/sh ein
> symlink auf dash ist. So wie ich die dash-Manpage verstehe, geht die
> dash, wenn stdin nicht auf ein Terminal zeigt (was bei startkde halten
> dürfte, /proc/<pid>/fd bestätigt dies), von einer Loginshell aus, und
> wertet /etc/profile aus.
>
> Irgendwann war das mal einfacher :-).

Ja. Ich finde das Gewirr an Konfigurationsdateien für die Shells etwas arg
komplex.

Zu Amiga-Zeiten gab es in der Hauptsache drei Dateien:

- S:Startup-Sequence - System-spezifisch, Finger weg, woran sich aber viele,
inklusive mir selbst nicht hielten :)

- S:User-Startup - alles globale Zeug für den einzigen Benutzer auf dem
System

- S:Shell-Startup - für einzelne Shells, das globale Zeug, inklusive
Erweiterungen zum Suchpfad gingen halt in die User-Startup, da vererbt.


Jaja, ich weiß, das kann auch nicht so viel. :)

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/201301071425...@lichtvoll.de

[Heiko Schlittermann]

Martin Steigerwald <Mar...@lichtvoll.de> (Mo 07 Jan 2013 14:02:14 CET):

> Am Montag, 7. Januar 2013 schrieb Heiko Schlittermann:
> > Martin Steigerwald <Mar...@lichtvoll.de> (Mo 07 Jan 2013 13:17:34 CET):
> > > Alternativ halt dann doch Shell-Spezifisch in:
> > > /etc/bash.bashrc
> >
> > In den rc-Files hat das eigentlich nichts zu suchen, meine ich.
> > Umgebungsvariablen werden vererbt, müssen also nur rechtzeitig gesetzt
> > werden. Die rc-Files werden bei jeder interaktiven Shell gelesen, wenn
> > sie keine Login-Shell ist.
>
> Hmmm, ja. Und selbst wenn sie eine ist:
>
> martin@merkaba:~> grep bashrc .bash_profile
> # include .bashrc if it exists
> #if [ -f ~/.bashrc ]; then
> # source ~/.bashrc
> if [ -e ~/.bashrc ]
> # execute .bashrc if it exists.
> . ~/.bashrc
> martin@merkaba:~> grep bashrc /etc/profile
> # The file bash.bashrc already sets the default PS1.
> if [ -f /etc/bash.bashrc ]; then
> . /etc/bash.bashrc
>
> Nun, PATH ist in /etc/profile definiert und nicht in der /etc/bash.bashrc,
> also scheint Upstream Deine Meinung zu teilen.

Schön. Und das Sourcen der rc-Files machen die Login-Shells über die
profile-Dateien, sonst würden die rc-Files nicht gelesen werden und
Funktionen (die normalerweise nicht vererbt werden, ebensowenig wie
Aliase) würden in der Login-Shell nicht zur Verfügug stehen. Wäre auch
wieder blöd.

> > Die Shell im Terminal zu einer Login-Shell zu machen, ist eine gute
> > Sache, der neue PATH gilt dann aber eben nur für Kinder von Prozessen im
> > Terminal (und natürlich die Shell im Terminal selbst.
>
> Warum? De facto ist sie doch keine. Ich habe mich nicht extra mit für die
> Shell anmelden müssen.

Ja, darum ist ja bei vielen Terminals die Shell keine Login-Shell. Das
mit der der Login-Shell im Terminal ist m.E. nur, um eben dieses Problem
mit Umgebungsvariablen zu „fixen“.

> > Wenn Du es in der gesamten X-Umgebung brauchst, solltest Du es in einem
> > der Scripte der XSession unterbringen.
>
> Ich hab Pfad-Anpassungen für mich persönlich einfach in der ~/.zshrc
>
> Ja, ist vielleicht auch nicht der optimale Ort, doch ich bin da irgendwann
> ausgestiegen bei der verschachtelten Logik, wer da was wann einbindet.

Bei der zsh weiß ich nicht, wie es geht. Bei der Bash ist es einfach:

Login-Shell: /etc/profile¹
~/.bash_profile|~/.bash_login|~/.profile ¹
von
…
~/.bash_logout


Interaktiv (keine Login-Shell):
/etc/bash.bashrc
~/.bashrc

andere: $BASH_ENV kann den Namen einer zu lesenden Datei enthalten

¹) In diesen Files sollte ausdrüclich /etc/bash.bashrc respektive
~/.bashrc gelesen werden.

Was gehört wohin?

In die profile-Files: Alles, was wir vererben können, i.d.R.
Umgebungsvariablen, umask

In die rc-Files: Der Rest, also Funktionen, Aliase

> > > Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist
> > > mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische
> > > Konfigurationsdateien. Könnte also sein, dass es so oder so
> > > shell-spezifisch ist, und dann würde ich die rc/env-Dateien
> > > bevorzugen, damit es auch für Nicht-Login-Shells passt.

Ich hatte gerade irgendwo gefunden, daß bei der Zsh das ausdrücklich
gemacht werden muß, wenn man an /etc/profile interessiert ist.

> > Nicht-Login-Shells sind eigentlich immer (mehr oder weniger direkte)
> > Kinder von Login-Shells und sollten die Umgebung geerbt haben.
>
> Demnach müsste der Pfad aber auch in X11 gesetzt sein. Zumindest eine KDE-
> Sitzung wird über ein Shell-Skript hochgefahren. Und auch mit anderen Setups
> dürften Shell-Skripte die Hauptrolle spielen. Bei Matthias hat aber
> irgendetwas diese Vererbungslogik unterbrochen.

Wenn ein Shell-Script die Sitzung hochfährt, ist diese Shell noch lange
keine Login-Shell oder interaktive Shell. Es ist einfach nur eine Shell
und interessiert sich für $BASH_ENV respl. $ENV (wenn sie /bin/sh hieß).

> > > Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber
> > > binden die anderen Dateien gar nicht ein:

…

> Hehe, korrekt oder nicht :). Ich erinnere mich noch gut an den umask-Bug-
> Report, wo es darum ging, wie man diese am besten global setzt. Mein
> aktueller Stand und das funktioniert auf der Arbeit tatsächlich so, ist
> pam_umask.
…
> Jow, man pam_env:

…

> $HOME/.pam_environment
> User specific environment file
> Das kann Matthias ja dann mal ausprobieren.

Dem habe ich nichs mehr hinzu zusetzen :)

[Heiko Schlittermann]

> Ja. Ich finde das Gewirr an Konfigurationsdateien für die Shells etwas arg
> komplex.

Bei Debian ist es noch sehr übersichtlich gegenüber dem, was SuSE da
versucht…

--
Heiko

[Heiko Schlittermann]

Dietz Pröpper <di...@rotfl.franken.de> (Mo 07 Jan 2013 13:58:57 CET):

>
> /etc/environment wird via pam ausgewertet, und funktioniert wie erwartet.
> Ob's für Shells so geht wage ich zu bezweifeln, spätestens wenn
> /etc/profile ausgeführt wird ist der PATH weg (da in /e/p explitit gesetzt)

Das ist ein guter Punkt. Warum eigentlich ist das so? Vielleicht weil
pam_env nicht nach UIDs unterscheiden kann?

> Hier funktioniert auch ein Eintrag in /etc/profile, das liegt vermutlich
> dran, dass ich kde verwende, startkde /bin/sh shebang't und /bin/sh ein
> symlink auf dash ist. So wie ich die dash-Manpage verstehe, geht die dash,
> wenn stdin nicht auf ein Terminal zeigt (was bei startkde halten dürfte,
> /proc/<pid>/fd bestätigt dies), von einer Loginshell aus, und wertet
> /etc/profile aus.

Huh? Wenn STDIN nicht auf ein Terminal verweist? Dann ist das doch
gerade keine Login-Shell und auch keine interaktive Shell… Wo hast Du
das gelesen? dash(1) verstehe ich da anders.

Wenn STDIN mit einem Terminal verbunden ist, oder -i verwendet wird, ist
es eine interaktive Shell. Wenn argv[0] mit einem „-“ losgeht, ist es
eine login-Shell.

[Dietz Pröpper]

Heiko Schlittermann:

> Dietz Pröpper <di...@rotfl.franken.de> (Mo 07 Jan 2013 13:58:57 CET):
> > /etc/environment wird via pam ausgewertet, und funktioniert wie
> > erwartet. Ob's für Shells so geht wage ich zu bezweifeln, spätestens
> > wenn /etc/profile ausgeführt wird ist der PATH weg (da in /e/p
> > explitit gesetzt)
>
> Das ist ein guter Punkt. Warum eigentlich ist das so? Vielleicht weil
> pam_env nicht nach UIDs unterscheiden kann?

Möglicherweise. Wobei es ein no brainer wäre, das ganze in /etc/profile nur
für uid==0 umzusetzen. Wobei ich mir einbilde, dass der path u.U. auch via
irgendwelche pam-Magie gesetzt werden kann.

> > Hier funktioniert auch ein Eintrag in /etc/profile, das liegt
> > vermutlich dran, dass ich kde verwende, startkde /bin/sh shebang't
> > und /bin/sh ein symlink auf dash ist. So wie ich die dash-Manpage
> > verstehe, geht die dash, wenn stdin nicht auf ein Terminal zeigt (was
> > bei startkde halten dürfte, /proc/<pid>/fd bestätigt dies), von einer
> > Loginshell aus, und wertet /etc/profile aus.
>
> Huh? Wenn STDIN nicht auf ein Terminal verweist? Dann ist das doch
> gerade keine Login-Shell und auch keine interaktive Shell… Wo hast Du
> das gelesen? dash(1) verstehe ich da anders.

Ich hatte kreativ interpretiert, Du hast natürlich Recht.

Wobei ein kurzer Blick in die Xsessions der $hier installierten Display
Manager einen neuen Verantwortlichen ergibt - sowohl Xsession von kdm, als
auch die von gdm3 rufen (u.a.) /etc/profile, damit braucht's hinterher
keine Loginshell mehr.

grz
Dietz

[Heiko Schlittermann]

Moin,

Dietz Pröpper <di...@rotfl.franken.de> (Mo 07 Jan 2013 15:30:14 CET):

> Heiko Schlittermann:
> > Dietz Pröpper <di...@rotfl.franken.de> (Mo 07 Jan 2013 13:58:57 CET):
> > > /etc/environment wird via pam ausgewertet, und funktioniert wie
> > > erwartet. Ob's für Shells so geht wage ich zu bezweifeln, spätestens
> > > wenn /etc/profile ausgeführt wird ist der PATH weg (da in /e/p
> > > explitit gesetzt)
> >
> > Das ist ein guter Punkt. Warum eigentlich ist das so? Vielleicht weil
> > pam_env nicht nach UIDs unterscheiden kann?
>
> Möglicherweise. Wobei es ein no brainer wäre, das ganze in /etc/profile nur
> für uid==0 umzusetzen. Wobei ich mir einbilde, dass der path u.U. auch via
> irgendwelche pam-Magie gesetzt werden kann.

Aber PAM läuft doch eigentlich komplett vor und nach der Sitzung ab, so
daß die /etc/profile alles kaputt macht..

Und die Manpage zu pam_env ist falsch. Man muß offenbar user_readenv=1
eintragen. (Huh, 87 Bugs…, das weckt ja Vertrauen.)

Und pam_env wird auch nicht von allen verwendet. Bei mir nur von

atd cron login openvpnas slim sshd su

Also z.B. nicht von sudo(8).

> Wobei ein kurzer Blick in die Xsessions der $hier installierten Display
> Manager einen neuen Verantwortlichen ergibt - sowohl Xsession von kdm, als
> auch die von gdm3 rufen (u.a.) /etc/profile, damit braucht's hinterher
> keine Loginshell mehr.

Und was machen die /etc/profiles dann, wenn die davon ausgehen, daß es
ein Terminal gibt und zum Beispiel mit dem Nutzer kommunizieren
möchten?

[Matthias Taube]

Am 07.01.2013 16:32, schrieb Heiko Schlittermann:
> Und was machen die /etc/profiles dann, wenn die davon ausgehen, daß es
> ein Terminal gibt und zum Beispiel mit dem Nutzer kommunizieren
> möchten?

Danke für Eure Hilfe.

Aber ich habe nun die Shell auf Login-Shell gesetzt und dann wird
/etc/profile gelesen.

Damit klappt alles wie es soll.

mfg
Matthias



--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)

Archive: http://lists.debian.org/kchohu$stj$1...@ger.gmane.org