Scripte in ~/bin: $PATH funzt nicht

[linuxlooser]

Hallo zusammen,

ich habe hier ein etwas seltsames Problem: auf 4 Maschinen (alle mit aktuellem Debian Bookworm) laufen meine Scripte in ~/bin bzw. ~/bin/scripte.

Code: Alles auswählen

/home/{benutzername}/.local/bin:/home/{benutzername}/bin:/home/{benutzername}/bin/scripte:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Diese Maschinen habe ich seit Buster immer nur aktualisiert.

Nun habe ich 'n Laptop günstig bekommen und Bookworm auf die leere SSD gespielt.
Und dort bekomme ich den Pfad nicht erweitert.

Habe eben noch mit Meld mir die Dateien
~/.bashrc
~/.bash_profile
~/.profile
angeguckt zwischen einer alten Kiste und dem neuen Laptop. Komplett identisch.

In der .profile findet sich der Eintrag, wie er auch dort viewtopic.php?p=650156#p650156 schon beschrieben wurde.

Code: Alles auswählen

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

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

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

und - wenn ich das richtig sehe - verweist die .bash_profile

Code: Alles auswählen

if [ -f ~/.profile ]; then
        . ~/.profile
fi

auf eben diese .profile.
So funzt das - wie gesagt - auf 4 alten Maschinen, regelmäßig auf das aktuelle Debian aktualsiert.
Nicht aber funzt das auf der neu installierten Maschine.

Hat sich da seither irgendwas geändert, was ich berücksichtigen müßte?

[rhHeini]

Stichwort usrmerge, spätestens mit Trixie geht da kein Weg mehr dran vorbei.

[JTH]

Stichwort usrmerge, spätestens mit Trixie geht da kein Weg mehr dran vorbei.

Usrmerge hat mit ausführbaren Dateien, die in /home/rhheini/bin liegen, nicht so viel zu tun


Mir wär auch nicht bewusst, das sich hier irgendwo etwas grundlegendes geändert hätte.

Und dort bekomme ich den Pfad nicht erweitert.

Du beobachtest also, dass sich $PATH nicht wie gewollt verändert? Oder stimmt $PATH, aber du siehst deine Kommandos nicht ohne absolute Pfade? Dann fiele mir als erstes der blöde Fehler ein, dass die Inhalte von ~/bin etc. vielleicht auf dem neuen Rechner einfach noch nicht ausführbar sind.

und - wenn ich das richtig sehe - verweist die .bash_profile […] auf eben diese .profile.

Die .profile wird von der Bash selbst (ohne diese extra Zeilen) ignoriert, wenn eine .bash_profile existiert. Machst du in der .bash_profile noch irgendwas an $PATH, was dem Sourcen von .profile in die Quere kommt?

Ansonsten, als rabiater Weg zum „Debuggen“: Pack ein

Code: Alles auswählen

set -x

oben in die aufgelisteten Dateien und beobachte, ob die PATH-Zuweisung überhaupt stattfindet oder womöglich nochmal „überschrieben“ wird.

[rhHeini]

Sorry, nehme alles zurück, habe nur /bin gesehen und die Tilde davor ignoriert.

[chrbr]

und - wenn ich das richtig sehe - verweist die .bash_profile

Code: Alles auswählen

if [ -f ~/.profile ]; then
        . ~/.profile
fi

auf eben diese .profile.

Die erste Zeile im Codeblock prüft, ob die Datei ~/.profile existiert. Dabei sind die eckigen Klammern die Kurzform für den Befehl "test". Die zweite Zeile wird ausgeführt, wenn die Bedingung in der if Abtrage wahr ergibt. Der Punkt bedeutet, daß die Datei ~/.profile gelesen und der Inhalt ausgeführt wird. In der fish Shell ist das entsprechende Kommando "source", nur so als Info. Unter man bash und man test gibt es ausführlichere Beschreibungen.

Aus dem Kopf weiß ich sowas auch nicht. Gerade die Kurzformen sind nicht intuitiv. Das hilft zwar nicht genau für Dein Problem, erklärt aber die Konstruktion mit dem if Block. Auch die Leerzeichen sind zum Teil notwendig.
Viele Grüße und viel Erfolg bei der Problemlösung,
Christoph

[linuxlooser]

Und dort bekomme ich den Pfad nicht erweitert.

Du beobachtest also, dass sich $PATH nicht wie gewollt verändert? Oder stimmt $PATH, aber du siehst deine Kommandos nicht ohne absolute Pfade? Dann fiele mir als erstes der blöde Fehler ein, dass die Inhalte von ~/bin etc. vielleicht auf dem neuen Rechner einfach noch nicht ausführbar sind.

Gemeint war folgendes: wenn ich auf den 4 alten Kisten "echo $PATH" abfrage, dann kommt das oben im ersten Beitrag gezeigte Ergebnis, also incl. der Erweiterungen in der .profiles-Datei.

Mache ich dasselbe in der neue aufgesetzten Kiste, dann erhalte ich

Code: Alles auswählen

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Und jetzt wird's verrückt:
Eben habe ich mich per ssh von einer alten Kiste auf den neuen Laptop verbunden und bekomme:

Code: Alles auswählen

{benutzername}@alteKiste:~$ ssh {benutzername}@192.168.xx.aaa
{benutzername}@192.168.xx.aaa's password: 
Linux fujitsu 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Aug 18 15:50:31 2024 from 192.168.xx.zzz
{benutzername}@fujitsu:~$ echo $PATH
/home/{benutzername}/bin/scripte:/home/{benutzername}/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

aaa = Fujitsu
zzz = alteKiste

und - wenn ich das richtig sehe - verweist die .bash_profile […] auf eben diese .profile.

Die .profile wird von der Bash selbst (ohne diese extra Zeilen) ignoriert, wenn eine .bash_profile existiert. Machst du in der .bash_profile noch irgendwas an $PATH, was dem Sourcen von .profile in die Quere kommt?

Nee, in der .bash_profile stehen wirklich einzig und allein diese drei Zeilen drin.

[HumiNi]

Und jetzt wird's verrückt:

Es ist ein großer Unterschied, wie du in die Kommandozeilenebene kommst: diekt auf die Konsole, über eine graphische Oberfläche und Start Terminal oder per ssh. Hast du das berücksichtigt?

[linuxlooser]

Es ist ein großer Unterschied, wie du in die Kommandozeilenebene kommst: diekt auf die Konsole, über eine graphische Oberfläche und Start Terminal oder per ssh. Hast du das berücksichtigt?

Nun, auf drei der vier alten Kisten läuft Cinnamon. Und dort öffne ich für die Anwendungen, die ich hier diskutiere (also Ausführen meiner Scripte), immer aus dem Nemo mittels Button in der Tool-Leiste in das Terminal der grafischen Oberfläche, dort rufe ich das Script auf (z. B. `pdftune.sh`- und wegen $PATH startet das Script aus ~/bin/scripte.
Dort funzt das.
Auf der neuen Maschine funzt genau das nicht, die Ergänzungen in $PATH sind nicht vorhanden.

Aber aufgrund Deines Hinweises: wenn ich mit Strg-Alt-F1 auf die Konsole gehe (was ich kaum jemals mache) und dort $PATH ausgeben lasse - dann ist das dort vollständig.
Also macht die grafische Oberfläche irgendwas kaputt - aber nur auf dieser einen Maschine ...

[michaa7]

viewtopic.php?p=1369190#p1369190

[linuxlooser]

viewtopic.php?p=1369190#p1369190

Danke, hab das mal gelesen, aber:
Wenn ich auf einer der drei anderen Kisten das hier ausführe

Code: Alles auswählen

$ echo $0
bash

dann lerne ich daraus: das ist keine login-shell => aber $PATH wird entsprechend der Angaben in .profile ergänzt.

Dasselbe Ergebnis erhalte ich auch auf meinem "Patienten" - dort wird $PATH aber nicht ergänzt.
Wie oben schon richtig festgestellt, ergibt dort die Anfrage via SSH eine login-shell.

Code: Alles auswählen

~$ echo $0
-bash

https://unix.stackexchange.com/a/46856 beschreibt genau das:

Login shells typically read a file that does things like setting environment variables: /etc/profile and ~/.profile for the traditional Bourne shell, ~/.bash_profile additionally for bash†, /etc/zprofile and ~/.zprofile for zsh†, /etc/csh.login and ~/.login for csh, etc.

Und weiter lese ich da:

When you log in on a text console, or through SSH, or with su -, you get an interactive login shell. When you log in in graphical mode (on an X display manager), you don't get a login shell, instead you get a session manager or a window manager.

It's rare to run a non-interactive login shell, but some X settings do that when you log in with a display manager, so as to arrange to read the profile files. Other settings (this depends on the distribution and on the display manager) read /etc/profile and ~/.profile explicitly, or don't read them.

Und genau das sehe ich hier: 3 Kisten mit Debian Bookworm Cinnamon (alle seit Buster aktualisiert) lesen die .profile, eine Kiste mit Debian Bookworm Cinnamon (neu aufgesetzt) liest das Ding nicht.
DAS ist mein Problem. Irgendwas muß da im Lauf zwischen Buster und Bookworm anders sein - das wäre die naheliegendste Erklärung eines Laien. Die Empfehlung im verlinkten Beitrag hier im Forum

Schieb dein Script nach /usr/local/bin

bringt mich nicht wirklich weiter, denn dann hab ich ständig das Theater mit der Synchronisation zwischen den Kisten (das Home-Verzeichnis wird synchron gehalten, das geht auch einfach mit User-Rechten, für den genannten Pfad muß ich ständig als root einloggen).

[juribel]

Du kannst das Skript besser verlinken statt es zu kopieren, das machst du ein Mal mit root-Rechten, und dann ist es immer aktuell. Notiere das dann auch in deinem Skript als Kommentar.

[linuxlooser]

hmm ... wie's aussieht löst eine ~/.xsessionrc mit dem Inhalt

Code: Alles auswählen

if [ -f ~/.profile ]; then
        . ~/.profile
fi

das Problem ... die war auf der neuen Kiste nicht vorhanden.
https://wiki.debian.org/EnvironmentVari ... ay_manager