Thunar hat PATH ~/.local/bin verloren

[micha2]

Gestern konnte ich in Thunar plötzlich keine eigenen Skripte ausführen, per Kontextmenü → Öffnen mit… Und zwar solche die Unterskripte aufrufen. Alle dies Skripte stehen in ~/.local/bin . Mit Öffnen mit… Datei test:

#!/bin/bash

echo -e "$PATH" | zenity --text-info --width=920 --height=1080 --font "mono"

bekomme ich diesen PATH

/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin

Im Terminal ist der vollständige PATH noch da:

$ echo $PATH
/home/micha2/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin

Wie bekomme ich ~/.local/bin wieder in den Suchpfad von thunar → Kontextmenü → Öffnen mit…?

[linux-aarhus]

English:
On Manjaro the path is generated by the drop-in file in /etc/profiles.d/home-local-bin.sh

Verify the file exist - then recheck your init scripts to locate possible changes to your PATH variable

Deutsch:
Auf Manjaro wird der Pfad durch die Drop-in-Datei in /etc/profiles.d/home-local-bin.sh generiert

Überprüfen Sie, ob die Datei vorhanden ist. Überprüfen Sie anschließend Ihre Init-Skripte erneut, um mögliche Änderungen an Ihrer PATH-Variablen zu finden

[micha2]

You can answer me in english.

The file /etc/profile.d/home-local-bin.sh exists:

case ":${PATH}:" in
  *:"$HOME/.local/bin":*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
esac

Where can i find all init scripts?

Is this file /etc/profile.d/home-local-bin.sh called every time, i use thunar → Kontextmenü → Öffnen mit… ?

[linux-aarhus]

Different shells uses different init scripts.

zsh uses files starting with .zsh
bash uses files starting with .bash

The path may be set or altered by any script - to fit the needs of the script.

What you see in thunar may be the result of thunar being called from another script which alters the path.

[micha2]

I dont know, which shell “thunar → Context menu → Open with… ?” uses?; or which scripts are called before execution of “thunar → Context menu → Open with… ?”.

I don’t think that thunar is called from a script. And if it does, from which script?

[megavolt]

Soll ich jetzt auch auf English? Wie auch immer. Ich hab in .bash_profile einfach export PATH=$HOME/.local/bin/:$PATH hinzugefügt und es zeigt den korrekten Pfad an. Habe dein Beispiel-Skript genommen, funktioniert.

[micha2]

Soll ich jetzt auch auf English?

Deutsch ist OK, wenn sich niemand anderes beschwert.

Nach einem Neustart habe ich unter “thunar → Kontextmenü → Öffnen mit… ?” wieder den Pfad ~/.local/bin/.

In meiner ~/.bash_profile steht aber nur

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

und in ~/.bashrc steht auch kein .local/bin.

Offensichtlich wird PATH=$HOME/.local/bin/:$PATH an einer anderen Stelle gesetzt.

Und ist das normal, dass bei längerem Nicht_neu_starten der PATH kaputt gehen kann?

Es wird wohl noch einige Zeit dauern bis ich in diesen Sachen fit bin …
Und vielen Dank für eure Unterstützung

[micha2]

Nach dem letzten Update ist das Problem wieder da: Ich kann über thunar → Kontextmenü keine eigenen Skripte aus ~/.local/bin/ ausführen. In $PATH fehlt ~/.local/bin/. Ich habe ausprobiert einzufügen …:

if [[ ! ":$PATH:" =~ :$HOME/.local/bin: ]]; then
	export PATH="$HOME/.local/bin:$PATH"
fi

… in den folgenden 4 Konfigurationsdateien:

~/.bash_profile
ruft auf:
[[ -f ~/.bashrc ]] && . ~/.bashrc

/etc/bash.bashrc

Ist die folgende Datei auch für bash relevant?:
~/.profile

In /etc/profile.d/home-local-bin.sh
steht bereits:

case ":${PATH}:" in
  *:"$HOME/.local/bin":*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
esac

Welche Konfigurationsdateien gibt es noch, in denen ich versuchen kann $PATH zu erweitern?

Wofür sind diese Dateien?:
/etc/skel/.bash_profile
/etc/skel/.bashrc

[AlexBoldt]

Soweit mir bekannt, liegen in /etc/skel (für skeleton) Dateien, die bei Anlage eines neuen Users in dessen Home-Verzeichnis kopiert werden.
Also Templates für die User-Anlage.

[Nachlese]

@micha2

Skripte aus ~/local/bin/ ausführen. In $PATH fehlt ~/local/bin/

Nur um ganz sicher zu sein, daß das hier kein Mißverständnis ist sondern nur ein Tippfehler:

Der Pfad ($PATH) wird durch /etc/profile.d/home-local-bin.sh
erweitert und enthält danach auch $HOME/.local/bin

$HOME/.local/bin
ist nicht dasselbe wie
$HOME/local/bin

Danach kommt dann, was in ~/.bashrc und in ~/.profile … steht.
Dort wird das u.U. wieder verändert, wenn Du dort was dran gemacht hast.

[micha2]

Danke, dass war ein Tippfehler. Ich meinte (ich habe es oben auch korregiert):

Nach dem letzten Update ist das Problem wieder da: Ich kann über thunar → Kontextmenü keine eigenen Skripte aus ~/.local/bin/ ausführen. In $PATH fehlt ~/.local/bin/. Ich habe ausprobiert einzufügen …:

OK, die Reihenfolge der Aufrufe/Abarbeitung ist dann diese:

1. /etc/profile.d/home-local-bin.sh
2. ~/.bash_profile (ruft [[ -f ~/.bashrc ]] && . ~/.bashrc auf)
3. ~/.bashrc

Im Terminal funktioniert es auch. Dort sind folgende Suchpfade gesetzt:

echo $PATH
~/.local/bin:~/.cargo/bin:/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin

In thunar funktioniert es nicht:

In einem Skript über Kontextmenü aufgerufen: echo -e "$PATH" | zenity --text-info --width=920 --height=1080 --font "mono"
Ausgabe: /usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin

Kann es sein, dass /etc/profile.d/home-local-bin.sh bei mir nicht ausgeführt wird?

[Nachlese]

Mir ist nicht klar was Du tust.
Um beim Beispiel zu bleiben:
ich habe diese Zeile in eine Datei geschrieben:

echo -e "$PATH" | zenity --text-info --width=920 --height=1080 --font "mono"

und sie dann als ~/.local/bin/test1 gespeichert

habe dann die Datei ausführbar gemacht:
chmod ug+x ~/.local/bin/test1

Wenn ich jetzt im Terminal
test1
schreibe und Enter drücke, wird sie ausgeführt - und gibt mir den vollständigen Suchpfad aus

Ich weiß nicht, was Du mit:

@micha2

thunar → Kontextmenü

meinst.

Wenn ich in Thunar nach ~/.local/bin/ navigiere
und dann auf die Datei klicke,
dann wird sie nicht ausgeführt, sondern im Editor geöffnet.
(das Öffnen im Editor ist die voreingestellte Aktion für eine Textdatei)

Es gibt im Kontextmenü noch: “Öffnen mit” - dort gibt es u.U. Vorschläge für Anwendungen - oder Du kannst Deine eigene definieren, eine aus der Liste wählen oder einen eigenen Befehl definieren.

Du sagst:

Nach dem letzten Update ist das Problem wieder da

Ich habe aber nicht gesehen, wie Du das damals gelöst bekommen hast - was Du getan hast damit es bis jetzt offenbar funktioniert hat.

ps:
das, was ich hier gemacht habe, ist ja kein script im eigentlichen Sinne
dafür sollte es wohl mit:
#!/bin/bash
als erste Zeile beginnen

Ich benutze Thunar äußerst selten - und nie zum starten von Programmen

[megavolt]

Bei mir funktioniert es nach wie vor. Hab es nicht mal entfernt… Teste mal:

sh -c 'echo $PATH'
bash -c 'echo $PATH'
zsh -c 'echo $PATH

[micha2]

@Nachlese

Mir ist nicht klar was Du tust.

Das habe ich etwas zu knapp beschrieben (gestern war es schon spät/früh morgens). Also: Ich möchte eigene Skripte (aus ~/.local/bin/) über thunar → Kontextmenü → öffnen mit ausführen. Hier ist meine ausführbare Datei ~/.local/bin/test1 :

#!/bin/bash
echo -e "$PATH\n»$1«" | zenity --text-info --width=920 --height=1080 --font "mono"

Ich habe noch ein echo "»$1«" reingeschrieben, damit es nicht ganz so sinnlos aussieht. Wenn ich jetzt irgendeine Datei nehme, darauf thunar → Kontextmenü → öffnen mit → mit anderer Anwendung öffnen aufrufe, dort unter Einen benutzerdefinierten Befehl benutzen /home/micha2/.local/bin/test1 eintrage und öffnen klicke, dann bekomme ich, z.B.:

/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin
»/home/micha2/.local/bin/test1«

[micha2]

@Nachlese

Ich habe aber nicht gesehen, wie Du das damals gelöst bekommen hast - was Du getan hast damit es bis jetzt offenbar funktioniert hat.

Damals hatte ich irgendwann ein kleines Skript ~/p geschrieben:

#!/bin/bash
PATH="$HOME/.local/bin:$PATH"

und immer, wenn ich ein Terminal geöffnet habe, zuerst . ~/p ausgeführt. (Bis ich source oder . entdeckt habe, hatte es noch eine Weile gedauert). Als dann irgendwann nach einem Update der fehlende Pfad wieder im Suchpfad PATH drinnen war hatte ich mich gefreut, dass ich Terminal-Fenster wieder einfach nutzen konnte; bis gestern …

[micha2]

@megavolt

Teste mal:

Alle 3 oder 4 Befehle

$ echo $PATH
$ sh -c 'echo $PATH'
$ bash -c 'echo $PATH'
$ zsh -c 'echo $PATH

liefern dasselbe:

/home/micha2/.local/bin:/home/micha2/.cargo/bin:/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin

Ich habe in ~/.bashrc am Ende eingetragen:

if [[ ! ":$PATH:" =~ :$HOME/.local/bin: ]]; then
	export PATH="$HOME/.local/bin:$PATH"
fi

Wenn ich das rausnehme, dann erhalte ich bei diesen 4 Aufrufen jeweils:

/home/micha2/.cargo/bin:/usr/local/bin:/usr/bin:/var/lib/snapd/snap/bin

Es fehlt nur /home/micha2/.local/bin: am Anfang von $PATH.

/etc/profile.d/home-local-bin.sh enthält nur den fehlenden Teil:

case ":${PATH}:" in
  *:"$HOME/.local/bin":*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
esac

mehr nicht. Kann es sein, dass diese Datei nicht ausgeführt/aufgerufen wird, beim Öffnen eines Terminal-Fensters und auch nicht bei thunar → Kontextmenü → öffnen mit ?

[gosia]

Hallo micha2,
das ist alles etwas widersprüchlich. Normalerweise musst Du nichts tun, um $HOME/.local/bin in den PATH zu bekommen, das ist per Default so, wenn ~/.local/bin existiert und dein PATH stimmt auch:

@micha2

echo $PATH
/home/micha2/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin

oder

@micha2

echo $PATH
$ sh -c 'echo $PATH'
$ bash -c 'echo $PATH'
$ zsh -c 'echo $PATH

liefern dasselbe:

/home/micha2/.local/bin:...

Wobei ich vom Verständnis her die gleichen Probleme wie @Nachlese habe, u.a. auch wie Du den PATH in Thunar anzeigst? Und was sind das für Skripte? Wenn Du denen keine Oberfläche verpasst (z.B. zenity) oder eine Ausgabenumleitung in eine Datei, sieht man eigentlich nicht, ob sie starten oder nicht. Auch der in Thunar angezeigte PATH spielt nur eine Rolle, wenn ein Skript aus ~/.local/bin/ ein anderes Skript aus ~/.local/bin/ aufrufen soll. Wenn z.B. das Skript ~/.local/bin/foo das Skript ~/.local/bin/bar aufruft, müsste das so passieren
bash foo
Insofern ist das starten von eigenen Skripten aus Thunar heraus etwas ungünstig, fällt in die Kategorie “kann man machen, geht aber anders besser…”

zum Schluss noch dies:
Wenn nötig, würde ich den PATH in der .bashrc so ergänzen

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

aber wie gesagt, stimmt doch so in deinem PATH (s.o.)
Und überraschenderweise ändert das Setzen deines Pfades nicht den Pfad, den Thunar sieht. Hätte ich nicht gedacht, habe im Moment auch keine Erklärung für, aber wie gesagt “geht aber anders besser…” (s.o.)

viele Grüsse gosia

PS.
da steht es doch

@micha2

Und zwar solche die Unterskripte aufrufen.

also mein foo → bar Beispiel. Wie konnte ich das nur übersehen Also probiere es mal mit meinem oben erwähnten Workaround, bis hier eine schlauere Lösung kommt.

[micha2]

Hallo gosia,

Normalerweise musst Du nichts tun, um $HOME/.local/bin in den `PATH* zu bekommen, …

Ja, so sollte es sein. Ich vermute, rust cargo, oder irgend etwas, das ich installiert habe, hat sich nicht sauber in den PATH eingetragen. Da ich mich nicht auskenne (Linux, Manjaro) welche Konfigurationsdateien den PATH aufbauen fürs Terminal (*) und welche für thunar, hoffe ich hier Hilfe darüber zu bekommen, um den Fehler verfolgen und fixen zu können.

zu *)
Soweit ich bis jetzt verstanden habe gilt für’s Terminal diese Reihenfolge dieser Konfigurationsdateien:

1. /etc/profile.d/home-local-bin.sh
2. ~/.bash_profile (ruft [[ -f ~/.bashrc ]] && . ~/.bashrc auf)
3. ~/.bashrc
   a) Stimmt die Reihenfolge?
   b) fehlen noch Konfigurationsdateien?

Wobei ich vom Verständnis her die gleichen Probleme wie @Nachlese habe, u.a. auch wie Du den PATH in Thunar anzeigst?

Das habe ich hier beschrieben: Thunar hat PATH ~/.local/bin verloren - #14 by micha2

Auch der in Thunar angezeigte PATH spielt nur eine Rolle, wenn ein Skript [A] aus ~/.local/bin/ ein anderes Skript [B] aus ~/.local/bin/ aufrufen soll.

Ja, das stimmt. Wenn ich nur das Skript A habe, dann kann ich unter Einen benutzerdefinierten Befehl benutzen den vollständigen Pfad von A angeben. thunar findet dann A und ruft A auf und übergibt die per Kontextmenü angeklickte Datei an A, als Parameter.

Insofern ist das starten von eigenen Skripten aus Thunar heraus etwas ungünstig, fällt in die Kategorie “kann man machen, geht aber anders besser…”

OK, wenn du eine Idee hast wie es anders besser… geht, dann bin ich neugierig darauf

Wenn nötig, würde ich den PATH in der .bashrc so ergänzen

Danke für die Idee. Das habe ich mal so eingebaut:

if [[ ! -d $HOME/.local/bin ]]; then
	echo -e "Fehler: '$HOME/.local/bin/' existiert nicht in '~/.bashrc' !" | zenity --text-info --width=920 --height=1080 --font "mono"
elif [[ ! ":$PATH:" =~ :$HOME/.local/bin: ]]; then
	export PATH="$HOME/.local/bin:$PATH"
fi

Und überraschenderweise ändert das Setzen deines Pfades nicht den Pfad, den Thunar sieht.

Ja, da ist mein Problem: Durch welche Konfigurationsdateien (in welcher Reihenfolge) wird der SuchPfad, den Thunar sieht, aufgebaut?

Viele Grüsse micha2

[Nachlese]

Thunar startet als:
Thunar --daemon
in Deinem Benutzerkontext.

Ich wüßte nicht, weshalb und woher Thunar einen anderen Pfad sehen sollte als den, den Du via
echo $PATH
zu sehen bekommst.

Vielleicht ist ja in
printenv
noch ein Hinweis enthalten.

Ich habe hier ein etwas über ein Jahr altes Manjaro Xfce (in einer VM) an dem ich praktisch nichts verändert habe,
insbesondere nicht in /etc

Der Pfad stammt zuerst aus /etc/profile

# Append our default paths
append_path '/usr/local/sbin'
append_path '/usr/local/bin'
append_path '/usr/bin'

# Force PATH to be environment
export PATH

Dazu kommt noch

/etc/profile.d/home-local-bin.sh

… nicht nur das - alles, was in /etc/profile.d ist … bei mir ist das jre und perl

Sonst nichts (von dem ich weiß).

In meinem $HOME wird nirgends am Pfad gefummelt.

$HOME/.local/bin ist bereits da - wegen:
/etc/profile.d/home-local-bin.sh

---

ps:
mit Thunar hab ich mich wenig abgegeben - nutze ich kaum, wie gesagt
Was ich aber weiß ist, daß das “draufklicken und dadurch starten” im mc tadellos funktioniert
auch für das Beispielscript.

[gosia]

Hallo Micha,

@micha2

Ich vermute, rust cargo, oder irgend etwas, das ich installiert habe, hat sich nicht sauber in den PATH eingetragen.

naja, halte ich für sehr unwahrscheinlich. Es könnte schlimmstenfalls vorkommen, dass sich irgendwas an der falschen Stelle in den Pfad einträgt, z.B. am Ende, obwohl es am Anfang besser wäre. Aber das hätte schon Bugmeldungen gehagelt. Und dass ein Teil des Pfades (bei dir ~/.local/bin) “herausgelöscht” wird, halte ich bei dem Mechanismus der automatisierten Pfadergänzung für noch unwahrscheinlicher. Das läuft ja immer nach dem Schema
PATH=neuerPfadTeil:$PATH
ab, so dass der alte Pfad = $PATH erhalten bleibt.
Aber mach doch mal einen Test und lege einen neuen User an, kontrolliere seinen Pfad und installiere anschliessend z.B. Rust, das beinhaltet ja auch Cargo, wenn ich mich recht erinnere.
Und wie Du schon richtig gesehen hast wird ~/.local/bin durch /etc/profile.d/home-local-bin.sh in den Pfad eingefügt. Alle diese Skripte in /etc/profile.d/ werden wiederum beim einloggen von /etc/profile gestartet. Anschliessend kommt in der Regel ~/.bash_profile → ~/.bashrc an die Reihe. So die grobe Reihenfolge.
Aber alle diese Skripte in /etc/profile.d/ sind systemweit - also für alle User - wirksam, so dass man eigentlich die Hände davon lassen sollte, es sei denn, man weiss ganz genau, was man macht. Wenn überhaupt, dann könnte man ein zusätzliches Skript in /etc/profile.d/ ablegen, aber ich rate dringend davon ab und wüsste auch keinen vernünftigen Verwendungszweck dafür.
Und Eingriffe in /etc/skel/* wären noch schlimmer, weil das Templates sind, wie schon erwähnt.

@micha2

wenn du eine Idee hast wie es anders besser… geht

“besser” ist natürlich subjektiv, aber “anders” wäre das Skript einfach übers Terminal aufzurufen, z.B.:
foo.sh
Wenn foo.sh in ~/.local/bin liegt und ~/.local/bin wiederum am Anfang des Pfades steht (was wie gesagt der Regelfall sein sollte), reicht dies völlig. Kein
bash /PFAD/ZU/foo.sh
oder
./foo.sh
notwendig.
Oder wenn Du Icons bevorzugst, dann einen Starter anlegen.

@micha2

Durch welche Konfigurationsdateien (in welcher Reihenfolge) wird der SuchPfad, den Thunar sieht, aufgebaut?

Das ist die 1-Million-Dollar-Frage. Gestern hätte ich noch gesagt, dass Thunar einfach den Pfad vom User übernimmt, dem ist aber nicht so. Offenbar sucht Thunar in so einer Art “Ur-PATH” (so will ich das mal nennen)
usr/local/bin/usr/bin
Ob und wo man da eingreifen könnte (und ob das überhaupt wünschenswert oder gar möglich ist) - keine Ahnung. Es wäre ja nur für eigene Skripte, die wiederum andere eigene Skripte aufrufen, notwendig. Ich will die ja nichts vorschreiben, aber solche Konstruktionen sollte man eigentlich vermeiden, zumindest wenn Du diese Skripte von Thunar aus aufrufen möchtest. Wenn doch, dann eben das “Unterskript” innerhalb des “Hauptskriptes” mit
bash Unterskript
aufrufen, wie schon im vorigen Post erwähnt. Das hat bei einigen Test, die ich inzwischen gemacht habe, funktioniert.
Aber wie gesagt, mwine Vorzugslösung ist der Aufruf durch
foo.sh
Was spräche dagegen?

@Nachlese

@Nachlese

ich wüßte nicht, weshalb und woher Thunar einen anderen Pfad sehen sollte als den, den Du via
echo $PATH
zu sehen bekommst.

genau darauf hätte ich vor kurzem auch gewettet
Aber ein Versuch mit einem Skript, das nur
echo $PATH
ausgibt, hat mich überzeugt, dass dem eben nicht so ist. Aber erklären kann ich es auch nicht.

viele Grüsse gosia