(gelöst) PATH in .profile nicht in $PATH

[Meillo]

Wenn du noch weiter schnüffel willst, wo/wann PATH wie gesetzt wird, ginge das auch über die einzelnen PIDs der verschiedenen laufenden Teile und /proc/$PID/environ.

[michaa7]

Ich denke das liegt ganz einfach an lightdm. Lightdm liest .profile nicht ein und das wurde von DEBIAN auch nicht als bug angesehen:

> .profile is *not* for graphical shells (use .xsessionrc for that,
> at least on Debian).
I guess I could source /etc/profile and ~/.profile in an .xsessionrc. I
dislike having to maintain a number of dotfiles (I used to have an
.xinitrc in the past and was content to remove it in favor of automatic
configuration and autostart files) for what looks like the same one
thing in my mind (setting up some environment variables), but I can live
with it.

https://bugs.debian.org/cgi-bin/bugrepo ... bug=636108

Ich denke das ist die Ursache. Und dann können wir scannen bis wir noch viel älter sind ...

Zwei Möglichkeiten zur Abhilfe:

- sddm drüberbügeln
- Path in .xsessionrc definieren (was genau müßte da rein?)

[fischig]

dumme Frage: Wozu brauchst du einen Login-Manager?

[michaa7]

dumme Frage: Wozu brauchst du einen Login-Manager?

Display-manager.

[michaa7]

...
In dem Zusammenhang weiß ich nochmal auf meinen vorigen Beitrag hier hin Die Hälfte von dem scheint untergegangen zu sein.
...

Neee, gdm3 ist hier halt nicht installiert. Aber du hattest recht, und mir ist das eben erst später aufgefallen. Der Unterschied zwischen sddm und lightdm ist wohl was das unterschiedliche Verhalten zwischen den beiden Rechnern bezüglich .profile ausmacht.

[Livingston]

micha, stopp!
.profile gehört zur bash und wird auch nur von dieser gelesen, und dann auch nur, wenn sie als Login Shell aufgerufen wird. Das ist der Fall bei den Terminals F1-F12, die ihrerseits die bash aufrufen, und bei den anderen Möglichkeiten, die ich schon beschrieben habe.
lightdm, gdm, ssdm und wie sie alle heißen, machen ihr eigenes Ding. Natürlich können sie theoretisch .profile auswerten, aber ob das der Fall ist, sollte man vielleicht vorher ermitteln, bevor hier noch mehr neue Ansätze durch die Gegend fliegen.
Wenn Du am Ende fluxbox startest, dann mach das doch regelkonform so, wie ich Dir das schon oben rausgepickt habe: viewtopic.php?f=29&t=180030&start=45#p1262091 Noch ein neues Fass aufmachen und hier blickt keiner mehr durch.

Z.B. sowas hier

Path in .xsessionrc definieren (was genau müßte da rein?)

Ja, geht alles, kann man machen, aber systematisch rangehen ist was anderes. Wenn Du da wieder was veränderst, sehe ich nicht, warum ich da hinterherjagen sollte. Meine Freizeit kann ich prima auch anders totschlagen.

[michaa7]

Gemach, gemach. Ich habe mindestens soviel Interesse daran das nach Lehrbuch zu lösen wie du ....

Nur bei deiner Lösung (~/.fluxbox/startup) frage ich mich sofort was da besonders regelkonform sein soll wenn es auf dem einen Rechner notwendig ist, auf dem anderen nicht.

Meine .xsessionrc "Lösung" ist nicht meine Erfindung, sondern das was im entsprechenden Debian Bug report (und einigen anderen Posting lightdm und .profile betreffend) als die logische und naheliegende Möglichkeit beschrieben wurde (für lightdm und ander DMs, die nicht wie wiederum andere .profile auswerten). Und natürlich würde mich am meisten interessieren was sddm macht.

Insgesamt möchte ich beiden Rechner möglichst ohne Unterschiede oder mit möglichst wenigen Unterschieden betreiben. Das spräche dafür den einen display manager gegen den anderen auszutauschen um ein einheitliches Verhalten zu erhalten. Ich glaube dass es da eine Meldung gab dass einer der beiden DMs nicht mehr so gut maintained würde, ich weiß nicht mehr welcher. Und deshalb eben nicht welchen ich wählen sollte. Ich hatte derartiges schon früher gemacht und eigentlich ging das gut. Und erstmal eine Lösung zu wählen wie sie vom Debian Maintainer vorgesehen ist ist eigentlich immer was ich anstrebe .... weil ich mich erstmal darauf verlasse, dass die das wirklich besser wissen als ich.

Also in soweit haben wir doch eigentlich das gleiche Ziel, nicht?

EDIT:

case $SHELL in
*/bash)
[ -z "$BASH" ] && exec $SHELL $0 "$@"
set +o posix
[ -f /etc/profile ] && . /etc/profile
if [ -f $HOME/.bash_profile ]; then
. $HOME/.bash_profile
elif [ -f $HOME/.bash_login ]; then
. $HOME/.bash_login
elif [ -f $HOME/.profile ]; then
. $HOME/.profile
fi
;;

Aus: cat /usr/share/sddm/scripts/Xsetup

Hier ist es also: sddm liest $HOME/.profile, lightdm macht das nicht.

Und dies hier beschreibt wie man das in Debian lösen sollte, wenn ich das richtig verstehe:
https://wiki.debian.org/Xsession

[fischig]

dumme Frage: Wozu brauchst du einen Login-Manager?

Display-manager.

Noch 'ne dumme Randbemerkung:
Der Unterschied besteht nach meiner Kenntnis nur in der Bezeichnung. Es ist dasselbe. Und ich benötige seit ca. 15 Jahren keinen mehr (was zu praktizieren ich aber niemandem aufdrängen will). Insofern war die Frage schon echt gemeint. Ansonsten will ich nicht weiter stören.

[tobo]

micha, stopp!
.profile gehört zur bash und wird auch nur von dieser gelesen,[...]

Nein, nur von der Bash gelesen wird das dot-Zeug, das auch ein bash im Namen hat (z.B. bash_profile, .bash_logout). ~/.profile wird von allen Bourne kompatiblen Login-Shells gelesen (z.B. sh und ksh aufwärts), in Abhängigkeit der jeweils eigenen Konfigurationsdateien.

Will man, dass der Terminalemulator eine Login-Shell ausführt, dann muss man das dem Terminal-Emulator sagen! Am Beispiel von (xterm, urxvt) gibt's die Möglichkeit einer (allgemeinen) Konfigurationsdatei ~/.Xresources, eines Parameters "urxvt -ls" oder des Aufrufs über die eingebundene Shell "xterm -e bash --login". Eine dieser Möglichkeiten wird doch dein Terminal sicher auch bereitstellen?!

[MSfree]

Nein, nur von der Bash gelesen wird das dot-Zeug, das auch ein bash im Namen hat (z.B. bash_profile, .bash_logout). ~/.profile wird von allen Bourne kompatiblen Login-Shells gelesen

Was glaubst du, wofür bash steht?
Das heitß nämlich Bourne Again Shell. Und selbstverständlich führt die bash auch ~/.profile aus.

[tobo]

Nein, nur von der Bash gelesen wird das dot-Zeug, das auch ein bash im Namen hat (z.B. bash_profile, .bash_logout). ~/.profile wird von allen Bourne kompatiblen Login-Shells gelesen

Was glaubst du, wofür bash steht?
Das heitß nämlich Bourne Again Shell. Und selbstverständlich führt die bash auch ~/.profile aus.

Du musst mein Zitat richtig lesen - das steht "nur" (einzig) die Bash liest ~/.profile. Ich schreibe mein Zeug in die ~/.profile, weil eben nicht nur die Bash diese Datei liest...
Und hättest du mein Zitat dringelassen oder dein Zitat nicht um die Beispiele abgeschnitten, dann wäre das auch klar!? Aber das ist hier ja Mode, irgendwelche sinnverstellende Textfragmente zu zitieren.

[michaa7]

...Und ich benötige seit ca. 15 Jahren keinen mehr (was zu praktizieren ich aber niemandem aufdrängen will). Insofern war die Frage schon echt gemeint. Ansonsten will ich nicht weiter stören.

Du machst vermutlich autologin?

Wie auch immer. Beseitigen würde es mein Problem (terminal-emulator brauch immer vollen pfad, weil er ~/bin nicht kennt) vermutlich nicht. In soweit wollte ich nicht das Thema wechseln.

Sollte jedoch dein impliziter Vorschlag für mein Problem zielführend sein bedürfte es ein, zwei klitzekleiner dementsprechender Hinweise, wo sich hier beides Überschneiden würde.

[Livingston]

Ich war letzten Abend leider auch schon was unkonzentriert. Die Datei .profile wird natürlich nicht nur von der bash als login-shell sondern auch von ein paar anderen gelesen. Und wenn da bash_profile steht, natürlich nur von der bash. Einige Namensgebungen machen da schon Sinn.
Meine Idee, mit grep herauszufinden, was im Home-Verzeichnis alles PATH verändern könnte, war 'ne kleine Schnappsidee, und ich dachte, man könnte so per Ausschlussverfahren herausbekommen, was da alles mitspielt.

Besser ist natürlich, systematisch in der "natürlichen" Umgebung anzusetzen, in diesem Fall fluxbox.
Warum lieber nicht .xsessionrc? Je nach Display-/Loginmanager (den man vielleicht ja auch mal austauschen will), wird diese Datei gelesen oder auch nicht.
Oder: Wenn Du X per Hand mit xinit oder startx startest, wird .xinitrc aber nicht .xsessionrc gelesen.
Also ist in Deinem Fall die sauberste Lösung, beim Window-Manager fluxbox anzusetzen, denn der sorgt ja letztlich für Deine gewohnte Arbeitsumgebung. Standardmäßig macht er ja wenig, nämlich Fensterdarstellung, ein kleines Menü bereitstellen und eben zum Start ein paar kleine Dinge ermöglichen.
Wenn Du in ~/.fluxbox/startup die Umgebung einmal richtig setzt, wird sie von allen Programmen und auch terminals/shells, die Du von Deinem fluxbox-Desktop aus aufrufst, geerbt - eben auch die PATH-Variable. Das wäre in meinen Augen der natürliche Ort, um so viele Dinge wie möglich organisiert zu kriegen, vor allem wäre es in Zukunft leicht zu warten. Da könnten auch noch andere Sachen, wie Einstellungen der locals oder ähnliches rein (aber das Fass machen wir besser erst mal nicht hier auf.)

Und wenn Du doch mal ganz ohne X arbeitest, oder Dich per ssh auf der Kiste einloggen möchtest, dann und nur dann greift die Datei .profile, da bash als Login-Shell aufgerufen wird. Aber wie wir ja inzwischen wissen, erfreut sich Deine .profile bester Gesundheit.

[michaa7]

...
Besser ist natürlich, systematisch in der "natürlichen" Umgebung anzusetzen, in diesem Fall fluxbox.
Warum lieber nicht .xsessionrc? Je nach Display-/Loginmanager (den man vielleicht ja auch mal austauschen will), wird diese Datei gelesen oder auch nicht.
Oder: Wenn Du X per Hand mit xinit oder startx startest, wird .xinitrc aber nicht .xsessionrc gelesen.
Also ist in Deinem Fall die sauberste Lösung, beim Window-Manager fluxbox anzusetzen, denn der sorgt ja letztlich für Deine gewohnte Arbeitsumgebung. ...

Das sind sehr interessante Ausführungen , gerade auch was den X-sessionstart per starx betrifft. Und so gesehen hast du recht.

Andererseits ...

das ist im Grunde ja keine Lösung für X (könnte ja auch unter einem anderen WM oder DE laufen) sondern "nur" für fluxbox (aber immerhin!). Nicht das ich ständig mein WM/DE wechsle (fluxbox bestimmt schon 10 Jahre), aber ich teste derzeit auch lxqt ... und dann müßte ich da vielleicht wieder nachforschen.

Die .xsessionrc "Lösung" erscheint mir nur deshalb auch angemessen, weil sie eben dem Debian way entspricht:

The Debian reference manual describes how the defaults work:

If the user has a ~/.xsessionrc file, read it.

If a specific session was selected in the DM (GDM, KDM, WDM, LightDM, ...) , run it.

...

Das Problem ist daher weniger die Frage was der natürlichste Weg wäre. Das Problem besteht darin dass es keinen verbindlichen Weg gibt und jeder Maintainer eines display-mangers dazu eine andere Auffassung vertritt die dann zu unterschiedlicher Konfiguration führt.

Im Sinne der Vereinheitlichung meiner Software und weil mittlerweile geklärt ist welcher display-manager was einliest oder nicht sehe ich für mich (und ausdrücklich nicht als die richtige, einzige) als Lösung
an auf dem Laptop statt lightdm auch sddm zu installieren.

Danke an alle Beteiligten für das Zusammentragen von Infos und für alle Lösungsvorschläge.

[Livingston]

Wenn das mit .xsessionrc gehen sollte, dann siehst Du das ja, wenn Du es ausprobierst. Wenn's nicht klappt, kannste ja immer noch meinen Vorschlag aufgreifen.
Also in ~/.xsessionrc eintragen:

Code: Alles auswählen

export PATH=blablablubb

Ausloggen, einloggen und schauen, ob's klappt.
Wenn nicht, raus mit der Zeile und rein in ~/.fluxbox/startup.

Ich drück Dir die Daumen.

[Meillo]

Die .xsessionrc "Lösung" erscheint mir nur deshalb auch angemessen, weil sie eben dem Debian way entspricht:

The Debian reference manual describes how the defaults work:

If the user has a ~/.xsessionrc file, read it.

If a specific session was selected in the DM (GDM, KDM, WDM, LightDM, ...) , run it.

Das Problem ist daher weniger die Frage was der natürlichste Weg wäre. Das Problem besteht darin dass es keinen verbindlichen Weg gibt und jeder Maintainer eines display-mangers dazu eine andere Auffassung vertritt die dann zu unterschiedlicher Konfiguration führt.

Strukturell gesehen ist diejenige Datei die passende, beim Login (egal ob im textuell oder grafisch) eingelesen wird, um das Environment zu veraendern.

Gut waere, wenn es eine etablierte, einheitliche Datei gibt, die von allen Loginmanagern eingelesen wird. Das ist, soweit ich das hier verstanden habe, mit der ~/.xsessionrc beabsichtigt, aber ggf. noch nicht von allen Loginmanagern beruecksichtigt.

Keine Ahnung wie sich die verschiedenen Login/Display/whatever-Manager zueinander verhalten. Entscheidend ist nur, dass ein Programm den Login anbietet und dieses Programm startet einen Prozess, der als Elternprozess sein Environment an alle vom User anschliessend gestarteten Programme vererben kann. Das ist die richige Stelle um anzusetzen.

[michaa7]

Gut waere, wenn es eine etablierte, einheitliche Datei gibt, die von allen Loginmanagern eingelesen wird. Das ist, soweit ich das hier verstanden habe, mit der ~/.xsessionrc beabsichtigt, aber ggf. noch nicht von allen Loginmanagern beruecksichtigt.

Genau so sehe ich das auch.

Ich habe nun im Sinne einer Vereinfachung der Wartung auch auf dem Laptop sddm installiert. Dadurch habe ich zwar leider das siduction theme für den Anmeldebildschirm verloren. Sonst funktioniert aber alles und .profile wird eingelesen ohne weiters Gefummle.

Ursache geklärt, Problem gelöst.

Danke nochmals an alle.