Heiko Schlittermann: > Dietz Pröpper <dietz@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
Attachment:
signature.asc
Description: This is a digitally signed message part.