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

[Meillo]

Wir muessen Schritt fuer Schritt das Setup durchgehen, um den Unterschied zu finden.

Ist denn auf beiden System die gleiche Version von Debian?

Du verwendest schon auch die bash?


Poste die Inhalte oder die Unterschiede oder vergleiche sie selber von:
~/.profile
~/.bash_profile
~/.bash_login
~/.bashrc
/etc/profile
/etc/bash.bashrc

An sich kannst du die ganzen Dateien auch nur nach ``PATH'' greppen.

Wenn diesbezueglich alles identisch ist, muessen wir weitersehen.

[michaa7]

Danke, werde ich Nachmittags tun.

Einstweilen der Hinweis:
Auf dem Desktop, wo das mit qterminal ja funktioniert, scheint qterminal jedoch *keine* login shell zu sein, dennoch ist ~/bin im $PATH.

Laut Infos aus dem netz müßte eine loginshell auf "echo $0" mit "-bash" antworten (zudem wechselt bei mir in der loginshell die Farbe des promts zu grün). Ich erhalte jedoch mit qterminal:

$ echo $0
/bin/bash

dennoch:

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

Das hebt das login shell Argument etwas aus den Angeln.

[JTH]

.profile wird nur von der Login-Shell eingelesen. Vielleicht liegt es daran.

Guter Punkt.

Trotz mehr oder weniger unangetasteter .bashrcs und .profiles ist bei mir überall ~/bin mit in PATH – sogar bei allen Anwendungen, die in der Desktop-Session gestartet werden. Habe gerade mal nachgeschaut, das scheint mir eine Eigenheit vom gdm3 zu sein, siehe hier. Vererbt sich dann an alles in der Desktop-Session gestartete. (Oder weiß jemand, wo das sonst herkommen könnte?)

Hast du evtl. unterschiedliche Display-Manager installiert, michaa7? Oder andere Teile im Hintergrunde, die sich unterscheiden?

[Meillo]

Halte dich nicht so sehr mit der Login-Shell auf. Lass uns lieber nachvollziehen, wo $PATH veraendert wird.

(Normalerweise ist nur die Shell, in die man sich einloggt, eine Login-Shell -- darum der Name. Alle weiteren muessen es nicht sein, auch nicht die Shells in Terminalemulatoren. Sie erben gleichermassen das Environment der Login-Shell und damit auch $PATH. Insgesamt ist aber egal an welcher Stelle $PATH angepasst wird, man muss es nur tun.)

Das Ziel ist vorerst, herauszufinden, wo auf dem Desktop-Rechner $PATH angepasst wird.

Neuere Standard-Configs testen oft, ob ~/bin existiert und fuegen es dann automatisch zu $PATH hinzu. Vielleicht hast du deine Config am Laptop mal veraendert und beim Upgrade ist damit eine veraenderte Standard-Config aus dem Paket nicht druebergeklatscht worden ... Es kann viele Gruende geben. Entscheidend jetzt ist aber erstmal den Unterschied zu finden. Danach geht es um Erklaerungen. Und im letzten Schritt um die Frage, wie du das Problem am sinnvollsten loest.

[michaa7]

Laptop:

~$ cat ~/.profile | grep PATH
# set PATH so it includes user's private bin if it exists
PATH="$HOME/bin:$PATH"

~$ cat ~/.bash_profile | grep PATH
cat: /home/mh/.bash_profile: Datei oder Verzeichnis nicht gefunden

~$ cat ~/.bash_login | grep PATH
cat: /home/mh/.bash_login: Datei oder Verzeichnis nicht gefunden

~$ cat ~/.bashrc | grep PATH
~$

~$ cat /etc/profile | grep PATH
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
export PATH

~$ cat /etc/bash.bashrc | grep PATH
~$

Desktop:

~$ cat ~/.profile | grep PATH
# set PATH so it includes user's private bin if it exists
PATH="$HOME/bin:$PATH"

~$ cat ~/.bash_profile | grep PATH
cat: /home/mh/.bash_profile: Datei oder Verzeichnis nicht gefunden

~$ cat ~/.bash_login | grep PATH
cat: /home/mh/.bash_login: Datei oder Verzeichnis nicht gefunden

~$ cat ~/.bashrc | grep PATH
~$

~$ cat /etc/profile | grep PATH
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
export PATH

~$ cat /etc/bash.bashrc | grep PATH
~$

So wie ich das sehe belaufen sich die Unterschiede auf exakt 0,0.

Beide Systeme sind (wie stets seit eineinhalb Jahrzehnten) Debian/sid(uction). Sie sind meist tagesaktuell, wenn nicht dann nur wenige Tage im Verzug, so auch heute. Die software ist im wesentlichen identisch, damit meine ich terminalemulatoren, WM (fluxbox) Kernel. Das system unterscheidet sich nur in der Grafik (desktop: nvidio; Laptop: AMD/ATI).
Nur Anwendungen habe ich nicht immer alle auf dem Schleppi, weil der eigentlich vor allem als musikbox dient.

[Livingston]

Beides, sowohl das Laptop als auch der Desktop habe kein KDE installiert, sondern fluxbox als WM.

Ich benutze zwar nicht fluxbox, aber in openbox gibt es die Datei ~/.config/openbox/environment, wo auch noch ein paar Variablen gesetzt werden können. Wenn's was ähnliches für fluxbox gibt, ist das auch ein Kandidat.

[JTH]

Ich bin ja ein Freund von grep Wenn du einfach mal drauflos suchen willst, wo es herkommen könnte, könnte sich so etwas finden:

Code: Alles auswählen

grep -EIrsl '/\.profile|/etc/profile' /etc/ /usr/{lib,share}

Bei mir bin ich damit auf die oben angedeutete /etc/gdm3/Xsession gestoßen. Vielleicht gibts in deinem Setup auch einen Verdächtigen.

[Meillo]

Neben der Suche nach weiteren Orten, zu der Livingston und JTH gute Tipps gegeben haben, koennte man auch pruefen, ob ~/.profile tatsaechlich gelesen wird.

Dazu fuegst du dort z.B. sowas ein:

Code: Alles auswählen

TEST=foo
export TEST

Dann startest du den Rechner neu oder meldest dich zumindest ab und neu an.

Anschliessend machst du eine Shell auf und pruefst mit:

Code: Alles auswählen

echo $TEST

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

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

[michaa7]

... 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.

JTHs greperei auf dem Desktop ergibt folgendes:

~$ grep -EIrsl '/\.profile|/etc/profile' /etc/ /usr/{lib,share}
/etc/sddm/Xsession
/etc/sddm/wayland-session
/etc/bash.bashrc
/etc/profile.d/bash-completion.sh
/etc/profile
/etc/apparmor.d/abstractions/bash
/etc/skel/.bashrc
/etc/skel/.profile
/usr/lib/byobu/include/config.py
/usr/share/sddm/scripts/Xsession
/usr/share/sddm/scripts/wayland-session
/usr/share/gtk-doc/html/glib/glib-Character-Set-Conversion.html
/usr/share/bash-completion/completions/libreoffice
/usr/share/bash-completion/completions/_modules
/usr/share/mc/help/mc.hlp
/usr/share/base-files/dot.bashrc
/usr/share/base-files/dot.profile
/usr/share/base-files/profile
/usr/share/doc/manpages-it/LEGGIMI
/usr/share/doc/libimage-exiftool-perl/html/install.html
/usr/share/doc/nvidia-driver/html/openglenvvariables.html
/usr/share/doc/HTML/ca/smb4k/index.docbook
/usr/share/doc/HTML/it/smb4k/index.docbook
/usr/share/doc/HTML/es/smb4k/index.docbook
/usr/share/doc/HTML/sv/smb4k/index.docbook
/usr/share/doc/HTML/de/smb4k/index.docbook
/usr/share/doc/HTML/nl/smb4k/index.docbook
/usr/share/doc/HTML/uk/smb4k/index.docbook
/usr/share/doc/HTML/en/smb4k/index.docbook
/usr/share/doc/xz-utils/README.Debian
/usr/share/doc/libvte-2.91-0/README.Debian
/usr/share/doc/fetchmail/fetchmail-FAQ.html
/usr/share/doc/openssh-client/faq.html
/usr/share/doc/base-files/README
/usr/share/doc/xterm/xterm.faq.html
/usr/share/doc/adduser/examples/adduser.local.conf.examples/bash.bashrc
/usr/share/doc/adduser/examples/adduser.local.conf.examples/profile
/usr/share/doc/adduser/examples/adduser.local.conf.examples/skel/dot.bash_profile
/usr/share/doc/texlive-doc/texlive/texlive-en/texlive-en.html
/usr/share/doc/texlive-doc/kpathsea/kpathsea.html
/usr/share/perl5/HTTP/Request/Common.pm
/usr/share/byobu/profiles/tmux
/usr/share/aptitude/README.es
/usr/share/aptitude/README.it
/usr/share/aptitude/README.nl
/usr/share/aptitude/README
/usr/share/aptitude/README.ru
/usr/share/aptitude/README.fr
/usr/share/aptitude/README.ja
/usr/share/aptitude/README.cs

Ich benutze zwar nicht fluxbox, aber in openbox gibt es die Datei ~/.config/openbox/environment, wo auch noch ein paar Variablen gesetzt werden können. Wenn's was ähnliches für fluxbox gibt, ist das auch ein Kandidat.

Nein, gibt es in fluxbox nicht.

[JTH]

~$ grep -EIrsl '/\.profile|/etc/profile' /etc/ /usr/{lib,share}
/etc/sddm/Xsession
/etc/sddm/wayland-session

Die beiden dürften dafür verantwortlich sein, den PATH aus /etc/profile und ~/.profile in der Desktopumgebung in der Environment zu haben, siehe wayland-session und Xsession. (Ohne dafür bashrc o.ä. anzupassen, was natürlich trivial wäre )

Beide deine Rechner sind auf dem selben Stand (Sid*)?! Läuft auf einem Wayland, auf dem anderen X11, da verschiedene Grafikkarten? (echo $XDG_SESSION_TYPE) Läuft auf einem fish o.ä.? Sehen die beiden obigen Session-Dateien auf beiden Rechnern gleich aus?

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

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

[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.