eigentlich™ sollten binaries aus /bin, /usr/bin vorrang haben vor dem /usr/local/ zeugs - also in dem Fall /bin/install

eine /usr/local/bin/install würde somit ignoriert und trotzdem die richtige /bin/install verwendet

bei PATH-binaries muss man eben bei der Namensgebung darauf achten, daß es keine Konflikte gibt

gleiches auch wenn alias o.ä. verwendet wird (wobei da eher gewollt ist daß das Original verändert wird, und im Shellscript wird der Alias dann ignoriert)

wenn stattdessen die falschen Binaries laufen dann geht gar nichts mehr
frostschutz schriebeigentlich™ sollten binaries aus /bin, /usr/bin vorrang haben vor dem /usr/local/ zeugs
Nope, genau darum gibt es ja /usr/local.
$ ls /
bin    dev/  home/  lib64        media/  opt/   root/  sbin  sys/  usr/
boot/  etc/  lib    lost+found/  mnt/    proc/  run/   srv/  tmp/  var/
$ which ls
/usr/bin/ls
$ su -c "echo 'echo foo' > /usr/local/bin/ls; chmod 755 /usr/local/bin/ls"
Passwort: 
$ exec bash # bash „neu laden“
$ ls /
foo
$ which ls
/usr/local/bin/ls
$ su -c "rm /usr/local/bin/ls"
Passwort: 
$ exec bash
$ ls /
bin    dev/  home/  lib64        media/  opt/   root/  sbin  sys/  usr/
boot/  etc/  lib    lost+found/  mnt/    proc/  run/   srv/  tmp/  var/
Die Reihenfolge wird durch die Umgebungsvariable $PATH bestimmt.
sed 's/:/\n/g' <<<"$PATH" | nl
     1	/usr/local/bin
     2	/usr/local/sbin
     3	/usr/local/bin
     4	/usr/bin
     5	/usr/lib/jvm/default/bin
     6	/usr/bin/site_perl
     7	/usr/bin/vendor_perl
     8	/usr/bin/core_perl
1 überschreibt 2, 2 überschreibt 3, 3 überschreibt 4, und so weiter.

Du kannst die Variable in der Konfiguration deiner Shell anpassen.

https://wiki.archlinux.de/title/Umgebungsvariablen#PATH
@Dirk, danke, bei mir setzt irgendwas in der Kette xdm<->fluxbox einen verquerten PATH. Dachte immer das gehört so bei ArchLinux :-) ... (und der Wiki-Link setzt es ja auch ans Ende)
Die neueste Arch-Installation die ich habe, sieht so aus. Was auch irgendwie meinem Verständnis der Rangfolge Verzeichnisse entspricht.
$ sed 's/:/\n/g' <<<"$PATH" | nl
     1	/usr/local/sbin
     2	/usr/local/bin
     3	/usr/bin
     4	/usr/bin/site_perl
     5	/usr/bin/vendor_perl
     6	/usr/bin/core_perl
Wird wohl Zeit, den Artikel mal zu aktualisieren.

Edit: Ich war mal so frei 🙂
@Dirk die PATH Geschichte wär schon fast nen neuen Thread wert... wenn du das Moderationstechnisch abtrennen möchtest.

Also, xorg-xdm (uuralt, benutzt außer mir wahrscheinlich eh keiner) setzt einen Gruselpfad

laut Sourcecode
resource.c:91:#ifndef DEF_USER_PATH
resource.c:92:# define DEF_USER_PATH ":/bin:/usr/bin:/usr/bin/X11:/usr/ucb"
resource.c:94:#ifndef DEF_SYSTEM_PATH
resource.c:95:# define DEF_SYSTEM_PATH "/etc:/bin:/usr/bin:/usr/bin/X11:/usr/ucb"
aber in der ArchLinux Binary speziell
$ strings /bin/xdm | grep /bin
/bin:/usr/bin:/usr/bin:/usr/ucb
( /usr/bin doppelt und /usr/ucb was zum Geier )

So da hab ich mir gedacht, gute Gelegenheit mal alte Zöpfe abzuschneiden. Also weg mit xorg-xdm und her mit, äh, was gibts da schönes ...? Okay, lightdm!

lightdm filtert aus irgendeinem Grund sbin-Sachen aus dem Pfad heraus.

Dann kommt die ArchLinux /etc/profile die das per appendpath wieder HINTEN ranhängt.
# Append our default paths
appendpath () {
    case ":$PATH:" in
        *:"$1":*)
            ;;
        *)
            PATH="${PATH:+$PATH:}$1"
    esac
}

appendpath '/usr/local/sbin'
appendpath '/usr/local/bin'
appendpath '/usr/bin'
unset appendpath
Ergebnis dementsprechend "/usr/local/bin:/usr/bin:/bin:/usr/local/sbin" und dass /sbin /usr/sbin fehlen, fällt bei Arch ja nur deshalb nicht auf, weil das bei Arch eben Symlinks aufs gleiche Verzeichnis sind (so gesehen auch Quatsch mehr als nur eins in den PATH zu setzen, aber bitte).

Ganz erstaunlich wieviele Programme der Meinung sind, am PATH rumknoddeln zu müssen.

Ich glaube mir ist das (in anderen Distributionen) einfach nie aufgefallen weil deren Profile einfach kurzen Prozess macht und den PATH statisch setzt und fertig.
frostschutz schriebIch glaube mir ist das (in anderen Distributionen) einfach nie aufgefallen weil deren Profile einfach kurzen Prozess macht und den PATH statisch setzt und fertig.
Da ist was dran. Man selbst kann in seiner .bashrc zum Beispiel ja auch $PATH setzen wie man es will. Da kann man auch den ganzen Mist, den einige Programme damit machen, auch wieder korrigieren. Das ist alles schon recht gut durchdacht. Im Zweifelsfall kann man Programme immer noch über ihren vollständigen Pfad aufrufen.
Bei allen Distris, die ich bisher benutzt habe (OpenSUSE, Fedora, CentOS, Debian, Arch Linux) ist die $PATH Variable standardmäßig so konfiguriert, dass /usr/local/bin und /usr/local/sbin ganz vorne sind.
Der, auch von mir u.U. genutzte Sinn dahinter ist, dass Systemadministratoren dort systemweite Standardwerkzeuge hinterlegen und überschreiben können.
Der OP im anderen Thread hat genau dies, leider unabsichtlich und ohne Kenntnis gemacht.
Für DAUs gibt es ~/.local/bin welches i.d.R. nach den globalen Pfaden eingereiht ist.
OK, also... ich hatte in meiner .bashrc althergebracht auch noch ein 'source /etc/profile' drin. Wenn man das bei ArchLinux macht, dann verdoppeln und verdreifachen sich die ganzen PATH-Sachen.

Nur /etc/profile nicht zu sourcen ist auch Mist weil mir wie gesagt irgendwas™ weiter oben meint, sbin-Pfade rausfiltern zu müssen oder aber was ich vorher hatte (bei xdm) irgendwelche Gruselpfade dazu und am Ende stimmt die Reihenfolge ganz und gar nicht.

Ich hab mir jetzt einen Würgaround gebastelt (Benutzung auf eigene Gefahr)

/etc/profile.d/zzz_path_fixer_upper.sh
#
# PATH Fixer Upper
#
# - make sure default paths are first (retain order otherwise)
# - replace path aliases with real path names
# - remove duplicate and nonexisting paths
#

FixerTodo="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
FixerDone=""

# fix our paths - adapted from /etc/profile :: appendpath()
FixerUpperPath() {
    [ -e "$1" ] && set -- "$(realpath "$1"/. 2> /dev/null)" || return
    case "::$FixerDone:" in
        *:"$1":*)
            ;;
        *)
            FixerDone="${FixerDone:+$FixerDone:}$1"
    esac
}

FixerTodo="$FixerTodo:"
while [ "$FixerTodo" ]
do
    FixerUpperPath "${FixerTodo%%:*}"
    FixerTodo="${FixerTodo#*:}"
done

PATH="$FixerDone"
export PATH

unset FixerTodo FixerDone FixerUpperPath
Und damit hab ich dann ein schön aufgeräumtes PATH (die Sachen die zuerst drin stehen sollen zuerst, doppeltes Zeug raus und was nicht existiert auch weg).

Ob allgemein /etc/profile eigentlich so gestrickt sein sollte, daß mehrfacher Aufruf keine Nebeneffekte hat, wie es im Moment der Fall zu sein scheint, tja...

weil im engl. Forum auch gerade jemand Probleme mit Pfaden hatte: https://bbs.archlinux.org/viewtopic.php?pid=1851743

ich hab jetzt erstmal die Nase voll von PATH und belasse es dabei ;-)
frostschutz schrieb Ob allgemein /etc/profile eigentlich so gestrickt sein sollte, daß mehrfacher Aufruf keine Nebeneffekte hat, wie es im Moment der Fall zu sein scheint, tja...
Ist es. Dafür ist die Funktion appendpath() gedacht.
Allerdings machen die Skripte unter /etc/profile.d/*.sh da nicht mit:
$ grep -r "setenv PATH" /etc/profile.d/
/etc/profile.d/android-sdk.csh:setenv PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/tools/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
/etc/profile.d/perlbin.csh:[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
/etc/profile.d/perlbin.csh:[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl
/etc/profile.d/android-emulator.csh:setenv PATH "${PATH}:${ANDROID_HOME}/emulator"
/etc/profile.d/jre.csh:setenv PATH "${PATH}:/usr/lib/jvm/default/bin"
Die appendpath wird ja direkt weggeputzt (unset) in /etc/profile, die Unterscripte können diese Funktion also nicht nutzen (oder halt per copy-paste bzw. selber abfragen)...
schard, bei dem von dir geposteten Output sehe ich aber nur .csh-Skripte, die nur zum Tragen kommen, wenn man die C-Shell benutzt. Tut das noch jemand?
Hm, stimmt. Da sind aber auch sh Skripte in dem Ordner, die allerdings nicht setenv aufrufen.
Die sh Scripte machen genau das gleiche, hängen sich halt anders an den Pfad hintendran.
[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[...]
export PATH
Okay, ich bin grad im Urlaub und konnte daher nicht selber schauen.

Anwendungsgetriebene Variablen sollten m.W. in einzelnen Dateien getätigt werden, die unter /etc/profile.d liegen. In den offiziellen Repos gibt es jedenfalls Pakete, die das so machen.