Forum: PC Hard- und Software Linux path-Expansion


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Taucher (Gast)


Lesenswert?

Gibt es eine Möglichkeit, Unterverzeichnisse automatisch bei der 
path-Expansion der bash mit durchsuchen zu lassen, ohne dass sie 
explizit in der Environmentvariable path genannt sind?

von Εrnst B. (ernst)


Lesenswert?

Taucher schrieb:
> Gibt es eine Möglichkeit

Ja.

Beschreib mal was du machen willst.

von Taucher (Gast)


Lesenswert?

Ich habe ein Verzeichnis mit bunt gemischten Skripten, das im path steht 
– da will ich Ordnung rein bringen, indem ich Unterverzeichnisse nach 
Themen anlege. Ich möchte aber nicht alle Unterverzeichnisse in den path 
eintragen.

Wie kann man der bash beibringen, automatisch auch die 
Unterverzeichnisse nach Skripten zu durchsuchen?

von Mark S. (voltwide)


Lesenswert?

indem man rekursiv sucht?

von Taucher (Gast)


Lesenswert?

Mark S. schrieb:
> indem man rekursiv sucht?

Gute Idee. Nur: wie bringt man der bash bei, dass sie das automatisch 
machen soll?

von Schukostecker (Gast)


Lesenswert?

Taucher schrieb:
> Ich habe ein Verzeichnis mit bunt gemischten Skripten, das im path
> steht – da will ich Ordnung rein bringen, indem ich Unterverzeichnisse
> nach Themen anlege. Ich möchte aber nicht alle Unterverzeichnisse in den
> path eintragen.
> Wie kann man der bash beibringen, automatisch auch die
> Unterverzeichnisse nach Skripten zu durchsuchen?

Falsche Herangehensweise: Du könntest das Bilden der $Path Variable 
automatisieren.

von Andreas B. (bitverdreher)


Lesenswert?

find sucht grundsaetzlich recursiv

: Bearbeitet durch User
von Schukostecker (Gast)


Lesenswert?

Oder Symlinks deiner Skripten mit find   bilden und dieses Verzeichnis 
in $PATH halten.

von Taucher (Gast)


Lesenswert?

Schukostecker schrieb:
> Falsche Herangehensweise: Du könntest das Bilden der $Path Variable
> automatisieren.

Da habe ich auch dran gedacht. Nur wenn das die bash selbst kann, dann 
muss man es nicht programmieren. Fragt sich nur, ob sie das kann.

Wildcards im PATH würden es tun, aber die werden dort nicht expandiert.

von Taucher (Gast)


Lesenswert?

Schukostecker schrieb:
> Oder Symlinks deiner Skripten mit find   bilden und dieses Verzeichnis
> in $PATH halten.

Das würde an dem Chaos im skript-Verzeichnis nichts ändern.

von Drago S. (mratix)


Lesenswert?

Interessante Frage, würde mich auch...

Ich denke an die includes von Konfigurationsdateien, welche überall in 
der /etc herumschwirren.

/etc/*/conf.d/*.conf werden von Haus aus rekursiv eingelesen und 
zusammengesetzt.

Mit der $PATH sollte es auch (irgendwie) gehen?

von Taucher (Gast)


Lesenswert?

Taucher schrieb:
> Wildcards im PATH würden es tun, aber die werden dort nicht expandiert.

Eine Möglichkeit wäre, in der .bashrc den PATH mit Wildcards einzutragen 
und dann eine Funktion aufzurufen, die die Wildcards expandiert und das 
Ganze dann PATH zuweist.

von Taucher (Gast)


Lesenswert?

Drago S. schrieb:
> /etc/*/conf.d/*.conf werden von Haus aus rekursiv eingelesen und
> zusammengesetzt.

Das macht das jeweilige Initialisierungsskript.

von Ein T. (ein_typ)


Lesenswert?

Taucher schrieb:
> Eine Möglichkeit wäre, in der .bashrc den PATH mit Wildcards einzutragen
> und dann eine Funktion aufzurufen, die die Wildcards expandiert und das
> Ganze dann PATH zuweist.

Man kann sich auch mit Anlauf in den Fuß schießen. Die Umgebungsvariable 
PATH ist sicherheitsrelevant, also setz' sie bitte von Hand. Das kann 
für ein paar blöde Unterverzeichnisse ja wohl nicht so schwierig sein.

von Taucher (Gast)


Lesenswert?

Mann, war das hilfreich… Du kannst es ja gerne zu Fuß machen, ich nicht 
– ich weiß schon was ich mache…

von Noch ein Kommentar (Gast)


Lesenswert?

Ganz anderer Ansatz - in deinem bin-Verzeichniss legst du Symlinks auf 
die verteilten Scripte an.

Wenn du eh schon solche Massen an Scripten hast, kommt es auf ein 
zusätzliches Script, was die Links anlegt, auch nicht mehr an.

von Paul Plan (Gast)


Lesenswert?

Taucher schrieb:
> Mann, war das hilfreich… Du kannst es ja gerne zu Fuß machen, ich nicht
> – ich weiß schon was ich mache
Offensichtlich nicht. Es gibt schon einen Grund, warum bash das nicht 
macht

von Εrnst B. (ernst)


Lesenswert?

Also so schwer wär das jetzt nicht,
1
PATH="$PATH$(find /mein/script/directory -type d -exec printf ':%s' {} \;)"
in die .profile, .bashrc, ...
Klappt zumindest solange du keine "bösartigen" Verzeichnisnamen hast.

Alternative war das symlink-Directory.
das ist auch per find & co schnell erstellt/aktualisiert.

Dritte Option wäre ein find nach allen ausführbaren Scripten unterhalb 
deines Script-Folders (gnu find: "-type f -executable", portabel mit 
"-perm +111"), und Anlegen von bash-aliases für diese.

Vermeidet teils Nachteile von Version 1 (ellenlange $PATH-Variable) und 
von 2 (zusätzliches Verzeichnis, Scripte müssen aus beiden Ordnern 
laufen können)
Behält aber den Nachteil von Version 2 bei, dass neue Scripte erst in 
einer frischen bash sichtbar sind.

von Taucher (Gast)


Lesenswert?

Meine Lösung:
1
PATH=$(gawk -v PATH=$PATH -f <(cat - <<-'_EOF_'
2
  BEGIN {
3
    tempfile = "/tmp/expand-path.tmp"
4
    path=""
5
    split(PATH, p, ":")
6
    for (i in p) {
7
      if (p[i] ~ /.*\*/) {
8
        system("file " p[i] " >" tempfile)
9
        while (getline f < tempfile) {
10
          if (f ~ /directory$/) {
11
            split(f, dir, ":")
12
            path = path dir[1] ":"
13
          }
14
        }
15
      } else {
16
        path = path p[i] ":"
17
      }
18
    }
19
    print path
20
  }
21
_EOF_
22
))

Das am Ende der .bashrc expandiert Wildcards am Ende eines Pfades in 
PATH

von Taucher (Gast)


Lesenswert?

Ein export an den Anfang von Zeile 1 schadet nicht…

von Bauform B. (bauformb)


Lesenswert?

Εrnst B. schrieb:
> Dritte Option wäre ein find nach allen ausführbaren Scripten unterhalb
> deines Script-Folders (gnu find: "-type f -executable", portabel mit
> "-perm +111"), und Anlegen von bash-aliases für diese.

> Behält aber den Nachteil von Version 2 bei, dass neue Scripte erst in
> einer frischen bash sichtbar sind.

Das sollte sich mit inotifywait(1) reparieren lassen. Wahrscheinlich 
braucht man find(1) dann nur noch einmal zu Anfang.

von Ein T. (ein_typ)


Lesenswert?

Taucher schrieb:
> – ich weiß schon was ich mache…

Ja, das habe ich schon oft gehört. Aber wenn Du es wüßtest, dann wärst 
Du bereits selbst auf einen Oneliner mit find(1) gekommen, und müßtest 
also nicht hier fragen. Und wenn Du es wirklich wüßtest, dann wäre Dir 
selbst klar, daß Dein Vorhaben gravierende Sicherheitsprobleme 
provoziert.

von Taucher (Gast)


Lesenswert?

ein_blöder_typ…

von Daniel A. (daniel-a)


Lesenswert?

Noch eine Variante für Bash:
1
export PATH="$PATH$( shopt -s globstar; printf ':%s' /mein/script/directory/**/; )"

von Taucher (Gast)


Lesenswert?

Daniel A. schrieb:
> export PATH="$PATH$( shopt -s globstar; printf ':%s'
> /mein/script/directory/**/; )"

Sehe ich das recht, dass damit auch Dateien, die in directory liegen, 
mit in den PATH übernommen werden?

Der Teufel steckt wie immer im Detail…

von Daniel A. (daniel-a)


Lesenswert?

Also bei mir nicht:
1
dpa@dragonfly:~/bin$ mkdir x
2
dpa@dragonfly:~/bin$ mkdir x/y
3
dpa@dragonfly:~/bin$ touch x/w
4
dpa@dragonfly:~/bin$ touch x/y/w
5
dpa@dragonfly:~/bin$ echo "$PATH$( shopt -s globstar; printf ':%s' "$PWD"/**/; )"
6
/home/dpa/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/dpa/bin/:/home/dpa/bin/x/:/home/dpa/bin/x/y/
7
dpa@dragonfly:~/bin$

von Taucher (Gast)


Lesenswert?

Ja, ich habs eben nachgelesen, dass der / am Ende des Pfades den 
Ausschlag gibt.

von Taucher (Gast)


Lesenswert?

OK, deine Lösung hat außerdem den Vorzug, dass das Wurzelverzeichnis 
explizit angeben muss. So wird verhindert, dass irgend welche anderen 
Pfade mit verwurstet werden. Zudem ist es schön kurz.

von cppbert (Gast)


Lesenswert?

Taucher schrieb:
> Wie kann man der bash beibringen, automatisch auch die
> Unterverzeichnisse nach Skripten zu durchsuchen?

das würde ich nicht machen - was spricht dagegen eine env zu haben für 
deinen script-root und dann per dieser direkt die script mit ordner 
aufzurufen

organisation ist irgendwie komisch wenn dann nachher alle namen 
eindeutig sein müssen - wenn du dann mal 50 scripte hast verlierst du 
jeden Überblick

was bringt dir das - vereinfachung Arbeitsfluss oder ruft du die Scripe 
sogar in anderen Scripten auf was deren Herkunft über den Path noch 
weiter verschleiert -> Wartungshölle

von Ein T. (ein_typ)


Lesenswert?

Taucher schrieb:
> ein_blöder_typ…

Stimmt, total. Vor lauter Blödheit bin ich auf sowas wie
1
PFAD=''
2
for path in $(find ~/<meineSkripte>/ -mindepth 1 -maxdepth 2 -type d); do
3
    PFAD="${PFAD}:${path}";
4
done

gekommen. Das läßt sich mit find(1) und (ggf. [e]grep(1)) feingranuliert 
steuern, ist aus Sicherheitssicht aber trotzdem mit Vorsicht zu 
genießen. Natürlich kann das auch direkt auf $PATH wirken. Ansonsten 
funktioniert ähnliches natürlich auch gut mit Aliassen und basename(1), 
dann muß man seine PATH-Variable nicht semikontrolliert erweitern.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.