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

[michaa7]

...

Ansonsten hatte Meillo ja ne gute Idee, da eine Fehlerquelle einzugrenzen.

Edit: Okay, Detektiv Meillo war auf der richtigen Fährte

Ja, eben. auf dem Laptop liest qterminal ".profile" nicht ein, auf dem Desktop schon.

Nur warum? Und wie ändern?.

[JTH]

Nur warum? Und wie ändern?.

Siehe meine Fragen oben zur Suche.

[Meillo]

qterminal bekommt den Pfad "/home/mh/bin" irgendwoher, aber wohl eben nicht aus .profile.

Das ist eine wichtige Erkenntnis.

Folglich ist alles irrelevant, was du in ~/.profile eintraegst, weil die Datei gar nicht eingelesen wird.


Nun gibt es zwei Wege von hier:

1) Wo wird ~/bin auf der Desktop-Maschine in $PATH eingetragen? (Da sind Livingston und JTH eher die Profis als ich.)

2) Wo solltest du $PATH anpassen, damit du dein eigentliches Problem loesen kannst? (Der einfachste Weg ist vermutlich ~/.bashrc. Dann muss muss es auch keine Login-Shell sein. Den Nachteil, den ich sehe: ggf. erscheint dann ~/bin mehrfach in $PATH, falls du Subshells oeffnest. Das ist aber mehr eine Unschoenheit als wirklich ein Problem.)

[Meillo]

... ob die Ausgabe ``foo'' ist.

Damit ist klar, dass die ~/.profile eingelesen worden ist. Folglich sollte dann auch $PATH korrekt sein.

EDIT:
klitzekleiner Fehler von mir, qterminal besteht auf dem Desktop den foo-TEST, sorry.

Ich vermute mal, du wirst jetzt gleich den Kopf schütteln:

Sowohl auf dem Laptop als AUCH auf dem Desktop besteht qterminal diesen Test *nicht*. Dennoch findet qterminal auf dem Desktop das in ~/bin liegende script UND, obwohl nach deinem Test ja .profile nicht eingelesen wurde steht ~/bin dort in $PATH (auf dem Laptop nicht).

mh@neutower:~$ echo $TEST

mh@neutower:~$ echo $PATH
/home/mh/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

qterminal bekommt den Pfad "/home/mh/bin" irgendwoher, aber wohl eben nicht aus .profile.

Also auf dem Desktop klappt alles, auf dem Laptop nicht.

... also jetzt nochmal langsam, dass wir nicht durcheinander kommen.

Wenn `neutower' der Desktop ist, dann ist der foo-Test doch nicht bestanden!

Es steht zwar ~/bin in $PATH, aber *nicht* ueber die ~/.profile!

Deine vorletzte Aussage ist korrekt.

Deine letzte aber nicht, denn keines der beiden Systeme liest ~/.profile. Dass ~/bin *irgendwie* (auf magische Weise) gesetzt wird, ist zwar schoen, aber mehr nicht.


Btw: Beim Debuggen ist es wichtig, sehr genau und Schritt fuer Schritt zu arbeiten.

[michaa7]

Sorry, mein Fehler. Neutower ist der Desktop. Ich hatte dort den Test falsch gemacht. Und dann nicht alles Falsche durchgestrichen

Richtig ist:

neutower=Desktop:

$ echo $TEST
foo

$ echo $PATH
/home/mh/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Also, auf dem Desktop wird .profile auch bei der Verwendung von qterminal eingelesen.
Genau das klappt auf dem Laptop nicht. Der foo-TEST schlägt fehl, ~/bin steht nicht im $PATH.
Allerdings klappt der foo-TEST auf dem Laptop bei der Verwendung von xterm. In Xterm läßt sich allerding konfigurieren, dass immer eine loginshell aufgemacht wird. Ohne dieses Setting klappt es auch mit xterm auf dem Laptop nicht.

Meine derzeitige Schlußfolgerung: ausser einer loginshell gibt es einen anderen Mechanismus der für das Einlesen von .profile sorgt. Dieser andere Mechanismus wirkt auf dem Dektoprechner, fehlt aber auf dem Desktop.

[Meillo]

Allerdings klappt der foo-TEST auf dem Laptop bei der Verwendung von xterm. In Xterm läßt sich allerding konfigurieren, dass immer eine loginshell aufgemacht wird. Ohne dieses Setting klappt es auch mit xterm auf dem Laptop nicht.

Was ich nicht verstehe:

Bei einem ersten Login am System, hat man immer eine Login-Shell und die liest ~/.profile.

Du schreibst nur von Terminal-Emulatoren. Hast du denn den Rechner mal neu gebootet oder dich komplett ausgeloggt und neu eingeloggt?

Weil wenn du das machst, dann sollten alle folgenden Shells des Systems (egal ob Login-Shell oder nicht) den geaenderten $PATH uebernehmen. Also auch jedes Terminalemulator-Fenster, egal ob das eine Login-Shell startet oder nicht.

[michaa7]

Bei einem ersten Login am System, hat man immer eine Login-Shell und die liest ~/.profile.

Das heißt sddm, der hier installierte Displaymanager ist eine loginshell?

Du schreibst nur von Terminal-Emulatoren.

Genau, nur darum geht es.

Hast du denn den Rechner mal neu gebootet oder dich komplett ausgeloggt und neu eingeloggt?

x-fach die letzten Tage und auch heute.

Weil wenn du das machst, dann sollten alle folgenden Shells des Systems (egal ob Login-Shell oder nicht) den geaenderten $PATH uebernehmen. Also auch jedes Terminalemulator-Fenster, egal ob das eine Login-Shell startet oder nicht.

Dann dürfte das Problem ja garnicht bestehen, Es geht nur um Terminal-Emulatoren, die ich nunmal nur starten kann, wenn ich mich an meinem Desktop via sddm angemeldet habe.

Und ich habe es eben -nach einem nochmaligen reboot- nochmals getestet:

Reboot
anmelden via Displaymanger sddm
roxterm -> besteht foo-TEST + ~/bin in $PATH
schließen roxterm
qterminal -> foo-TEST schlägt fehl + ~/bin nicht in $PATH

EDIT:

ließe sich mit strace (oder sonst einem Programm) nicht irgendwie feststellen, welche dateien qterminal beim starten anlangt? Ich habe man strace mal angeschaut, aber das ist für mich ein dschungel. BTW, das starten von qterminal aus eine anderen emulator heraus gibt keine anhaltspunkte.

[Meillo]

Hast du denn den Rechner mal neu gebootet oder dich komplett ausgeloggt und neu eingeloggt?

x-fach die letzten Tage und auch heute.

Okay. Das hattest du, glaube ich, bisher noch nicht explizit geschrieben.

Weil wenn du das machst, dann sollten alle folgenden Shells des Systems (egal ob Login-Shell oder nicht) den geaenderten $PATH uebernehmen. Also auch jedes Terminalemulator-Fenster, egal ob das eine Login-Shell startet oder nicht.

Dann dürfte das Problem ja garnicht bestehen, Es geht nur um Terminal-Emulatoren, die ich nunmal nur starten kann, wenn ich mich an meinem Desktop via sddm angemeldet habe.

Und ich habe es eben -nach einem nochmaligen reboot- nochmals getestet:

Reboot
anmelden via Displaymanger sddm
roxterm -> besteht foo-TEST + ~/bin in $PATH
schließen roxterm
qterminal -> foo-TEST schlägt fehl + ~/bin nicht in $PATH

Dies verwundert mich ein bisschen.

Kannst du mal bitte eine Konsole oeffnen (Strg-Alt-F2 ... oder F3 ... F6), dich dort anmelden und dort den foo-TEST machen und $PATH ausgeben.

Mit Strg-Alt-F7 kommst du wieder zurueck zu grafischen Oberflaeche.

[Livingston]

Meillo, wenn ein Loginmanager (gdm oder was auch immer) verwendet wird, dann wird keine login-shell gestartet. Innerhalb der X- oder Wayland-Oberfläche startet man Terminals fast immer ohne login. Deshalb frage ich mich, ob .profile hier überhaupt eine Rolle spielt.
Icewm scheint mir hier ein Kandidat zu sein, GUIs setzen ja gerne beim Starten Umgebungsvariablen. Leider habe ich von icewm keinen Plan.

Was man noch machen kann: Im Homeverzeichnis rekursiv nach allen Dateien suchen, die die Angabe "PATH=" enthalten:

Code: Alles auswählen

$cd ~
$grep -R -l -I -e "^PATH=" -e "[ \t]PATH=" .* * 2>/dev/null

Was es tut:
grep sucht rekursiv (-R) nach Ausdrücken, deren Zeilen mit "PATH=" beginnen (^PATH=) oder wo mindestens ein Leerzeichen bzw. Tabulatorzeichen ([ \t]+) vor "PATH=" steht, und zwar in allen normalen (*) und versteckten (.*) Dateien/Verzeichnissen. grep soll Binärdateien nicht durchsuchen (-I) und nur die Dateinamen (-l) ausgeben.

Alles andere wird mir hier gerade zu unübersichtlich.

WARNUNG: Je nachdem, was man alles in sein Home-Verzeichnis reingepackt hat, kann das Durchsuchen sehr lange dauern. Eine Stunde, wenn man's übertrieben hat.

EDIT: Das "+" im grep-Ausdruck gestrichen. Ist unnötig und verlängert die Suche.
EDIT2: Das "&" kurz vor Ende der Zeile muss auch weg. Die Umleitung (2>/dev/null) schickt grep-Fehlermeldungen ins Nirvana, statt auzugeben: "Is'n Verzeichnisname, kann ich nicht durchsuchen". Ist nur Kosmetik, macht aber die Ausgabe übersichtlich.

[michaa7]

...

Kannst du mal bitte eine Konsole oeffnen (Strg-Alt-F2 ... oder F3 ... F6), dich dort anmelden und dort den foo-TEST machen und $PATH ausgeben.

Gemacht. Beides ok.

[Livingston]

Was heißt ok? Was wurde denn ausgegeben?

[michaa7]

...

Code: Alles auswählen

$cd ~
$grep -R -l -I -e "^PATH=" -e "[ \t]PATH=" .* * 2>/dev/null

Was es tut:
...

So wie im moment habe ich die Laptopplate noch nie rödeln hören, da wird grad jedes Steinchen umgedreht

[michaa7]

Was heißt ok? Was wurde denn ausgegeben?

Naja, beim foo-TEST foo und und ~/bin steht in $PATH , das ist doch worum es bei der Frage ging?

[Livingston]

Ah, sorry, ich dachte erst, es bezog sich auf meinen Post. Ja, der Tag ist lang und langsam ist meine Konzentration weg.

[Livingston]

Alles, was ich hier empfehle, mache ich natürlich auch auf meiner Kiste. Da ich sehr viele Softwarepakete und source code runtergeladen habe, rödelt das Teilchen bei mir schon seit 'ner halben Stunde und spuckt zwischendurch auch was aus. Vieles kann man dann ausschließen, wenn man mal drüberschaut. Wäre ja wohl gelacht, wenn wir bei Dir nicht fündig werden.

[michaa7]

https://nopaste.debianforum.de/41246

Das ist erstmal Teil 1, dann ist das ganze hängen geblieben. Eben neu gestartet.

EDIT:

Auch im zweiten Durchlauf ist an der gleichen Stelle Schluß ohne dass ein promt erscheint. Die Platte rödelt aber nicht mehr.

[Meillo]

Meillo, wenn ein Loginmanager (gdm oder was auch immer) verwendet wird, dann wird keine login-shell gestartet.

Aha ... das war mir nicht bewusst. Danke.

Dann befinden wir uns hier in Gegenden von denen ich keine Ahnung habe. Ich mache es mir dann mal auf den Zuschauerplaetzen gemuetlich und versuche was dabei zu lernen.

[Livingston]

Mir ist gerade ein peinlicher Fehler im Kommando aufgefallen. Die Angabe "* .*" findet auch alles im Verzeichnis "..", also eine Ebene höher. Von da aus läuft die Suche regulär weiter, also auch wieder die Ebenen unterhalb von ".."
Ich hoffe, dass wird keine Endlosschleife. Wenn Du Wiederholungen siehst, würde ich an Deiner Stelle abbrechen, neues ist dann eh nicht mehr zu erwarten.

[michaa7]

Nee, Wiederholungen seh ich keine, aber es hört an der genannten Stelle auf ohne zu einem promt zurückzuzkehren, so dass ich nicht sicher bin ob grep wirklich durch ist. Aber sowohl nach Geräusch als auch nach Festplatten-Zugriffs-Diode tut sich nichts mehr.

Ich habe zwischenzeitlich mit

Code: Alles auswählen

strace -f -e trace=open qterminal

versucht herauszufinden, was qterminal beim Start einliest. Leider gibt das dann nur die PIDs der Prozesse aus (mehrfach qterminal, einmal /bin/bash), aber es ist so nicht sichtbar worauf die einzelnen qterminal Prozesse zugreifen. Du hast da nicht zufällig eine Idee wie man an diese Info käme?

EDIT:
Ich habe nurn doch einen Unterschied gefunden, der eine Rolle spielen könnte, gerade was dan login und vielleicht auch das Einlesen betreffen könnte. Ich meine nach dem was Livingston sagt muß ja, wenn es nicht eine loginshell selbst ist, irgend ein Prozess .profile lesen und an den user PATH anhängen. Nun ist als Displaymanger auf dem Desktop sddm installiert, dort gibt es in der *STANDARD*-config einen User default path *ohne* ~/bin. wie das bei mir aussieht kann ich nicht sagen, weil da in der /etc/sddm.config nichts dementsprechendes steht. Abedr irgendwie muß das system ja von .profile erfahren, sonst würde das auf dem Desktop ja nicht funktionieren.

Wie ich nun festgestellt habe ist abe, entgegen meinr bisherigen Annahme, auf dem Laptop *nicht* sddm , sondern lightdm installiert. Vielleicht funktioniert hier das einlesen von .profile anders? Zumindest ist ein ein Unterschied in systemrelevanter Software, der hier bislang unerwähnt blieb.

[Livingston]

Zur Suche: Wenn sich nichts mehr tut, kannste wohl abbrechen. Es verschachtelt sich wahrscheinlich immer weiter und gräbt sich in unendliche Tiefe, die es eigentlich nicht gibt.
Auf jeden Fall war der Output von Teil 1 schon mal interessant, weil nichts ungewöhliches drin steht.
Mal was zum Thema Login Shell: Heutzutage kommt man damit kaum noch in Berührung. Sie wird nur in drei Fällen aufgerufen:
1. Wenn Du Dich direkt in der Textkonsole einloggen willst (die Dinger die man mit Funktionstasten Alt+F1...F12 erreicht)
2. wenn Du bzw. ein Programm die shell als Login Shell aufrufst, also z.B. wenn Du ein Terminal startest und darin ein weiteres mit bash -l USERNAME aufrufst.
3. Außerdem erreicht man eine berühmte Login Shell über den Befehl su - (aber darum geht's hier nicht).

Starte ich z.B. bei ein xterm, wird keine Datei .profile aufgerufen, da keine Login Shell im Spiel ist, sondern nur eine einfache, nämlich bash ohne Schnickschnack und Gedöns. Was geladen wird, ist die Datei .bashrc.
Ein Login-Manager wie gdm ist auch keine Login Shell, auch wenn er dem Namen nach den Job einer solchen übernimmt.

Was aber viele (alle?) Umgebungen und Fenstermanager wie kde, gnome, icewm ermöglichen, ist das Setzen von Umgebungsvariablen für alle Prozesse, die darunter laufen. Bei meinem openbox habe ich schon die Datei ~/.config/openbox/environment erwähnt, und ich denke, das ist der Punkt, wo wir bei Dir ansetzen sollten. Jetzt wäre es gut, wenn sich jemand meldet, der von icewm Ahnung hat. Das ist leider nicht so mein Ding. Willy4711 will doch bestimmt mal wieder eine neue virtuelle Umgebung testen
_____

Zu qterminal: Da brauchst Du nicht weitersuchen. qterminal ruft keine Login Shell auf. Wahrscheinlich kann man es mit ein wenig gut Zureden mit der Kommandozeile dazu bringen, aber sinnvoll wäre das nicht (oder nur in wenigen Fälle, z.B. um direkt eine root shell zu kriegen, wo man sich mit Passwort als root anmelden muss). Um sicher zu gehen, können wir ja trotzdem noch mal mit strace drauf los gehen, aber strace ist ein Monster und heute wusel ich mich da nicht mehr mit rum.
_____

Fazit: Wir sind wahrscheinlich gar nicht weit vom Ziel entfernt, aber lass uns da besser morgen weitermachen. Heute bin ich zu platt dafür.

[michaa7]

Zu... Jetzt wäre es gut, wenn sich jemand meldet, der von icewm Ahnung hat. ...

fluxbox, nicht icewm

Und möglicherweise hast du meine neue Ergänzung bezüglich Desktop/sddm <-> Laptop/lightdm noch nicht gesehen. Zudem habe ich im Netz ein posting ggefundem, in dem gesagt wird, dass lighdm (wohl im Gegensatz zu sddm) .profile nicht einliest! Falls das tatsächlich so ist wäre das die klare Ursache. Ich frage mich ob ich nicht einfach sddm drüberbügeln sollte.
_____

Fazit: Wir sind wahrscheinlich gar nicht weit vom Ziel entfernt, aber lass uns da besser morgen weitermachen. Heute bin ich zu platt dafür.

Ok, alles klar, bin ich auch dafür. Danke soweit für deine/eure Unterstützung.

[Livingston]

fluxbox, nicht icewm

Und möglicherweise hast du meine neue Ergänzung bezüglich Desktop/sddm <-> Laptop/lightdm noch nicht gesehen.

Siehst Du? Genau das meine ich: Lieber morgen weitermachen

[michaa7]

[Livingston]

Einen hab ich noch.
Hast Du eine Datei namens ~/.fluxbox/startup? Da gehört sowas rein bzw. ergänzt:

export PATH=blablabla

Wenn nicht, einfach mal mit nem Texteditor erstellen, eintragen, dann noch chmod 755 ~/.fluxbox/startup hinterher, damit die Datei ausführbar wird.
Neustart und beten. Sollte eigentlich klappen, sagen die Kollegen drüben bei Arch Linux https://wiki.archlinux.org/index.php/fluxbox#Autostart.

[JTH]

Zudem habe ich im Netz ein posting ggefundem, in dem gesagt wird, dass lighdm (wohl im Gegensatz zu sddm) .profile nicht einliest! Falls das tatsächlich so ist wäre das die klare Ursache.

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

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.