Der Martin: bash - Globale Umgebungsvariable im Script ändern

Beitrag lesen

Hallo,

Aber wie rettet mich das vor Scripts, in deren shebang-Zeile ein ganz anderes Verzeichnis für das erforderliche Programm steht, als es in meiner eigenen Installation der Fall ist?
Dann ist es schon zu spät. Wenn die Shebang gleich auf #!/usr/bin/env php steht, dann wird PHP gestartet, ohne dass das Script genau wissen muss, wo die "php.exe" liegt.

ja, gut. Das ist eber nicht der typische Fall. Typisch ist eher, dass in der shebang-Zeile "hart" auf einen der üblichen Installationspfade verwiesen wird. Also FAIL.

Ja, genau so gehe ich vor. Wobei meine Sandbox in der Regel eine VM ist. Programme, die nicht mein Vertrauen haben, kommen vorläufig nicht auf mein Alltags- und Produktivsystem.
Das mag mit deiner Alles-sperren-plus-Whitelist-Einstellung zuzüglich deines Sachverstands wunderbar harmonieren, ist aber keine Option für die Massen, die eher die Neugier in den Vordergrund stellen.

Nun, ich gehe davon aus, dass auch Linux nicht die typische Option für die Massen ist, sondern eher für eine Minderheit von technik-affinen Experten.

Geänderte Environment-Einträge? Ich sag's mal so: WENN ein Script das Environment ändert, dann hat das doch normalerweise einen Sinn.
Möglicherweise, aber was weiß denn ein Programm (du darfst hier nicht nur Shellscripts betrachten) von der aufrufenden Umgebung und was sie so für Bedürfnisse hat?

Ich betrachte im Moment *ausschließlich* Shellscripte (aka Batchdateien), weil der Aufruf eines weiteren Programms als Kindprozess *immer* ein neues Environment bekommt. Es geht also nur darum, dass eine Batchdatei bevorzugt im Kontext (d.h. Environment) der aktiven Shell ausgeführt wird und auch deren Environment manipulieren darf und soll.

So long,
 Martin

--
Du kannst dem Leben nicht mehr Tage geben.
Aber dem Tag mehr Leben.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(