nicht angemeldet dedlfix
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Hi Leute,
da hier ja auch einige Linux-Versierte zu Gange sind, mal folgende Situation:
Ich habe ein Script in irgendeinem Verzeichnis "rumliegen".
Nun möchte ich gerne, dieses Verzeichnis temporär dem Suchpfad hinzufügen.
PATH=$PATH:~/bin
botmgr --status
funktioniert einwandfrei im Terminal (angenommen das Script liegt in ~/bin).
Sobald ich den Terminal schließe sind ja nun auch diese Manipulationen wieder weg (gewollt).
Was ich aus einer zweistündigen Google-Sitzung in Erfahrung gebracht habe, ist das jeder Terminal seinen eigenen Scope bekommt, so wie jeder Kindprozess.
Ich würde es gerne ermöglichen, dass man einfach einmal nur etwas wie ~/bin/botmgr --tmpregister eingeben muss und das Script PATH ändert.
Da allerdings das Script seinen eigenen Scope hat, wirkt sich das nicht auf das Terminalfenster aus. Und ein export PATH=$PATH:${DIR} gilt ja auch nur für Kindprozesse.
Lange Rede, kurzer Sinn: Gibt es einen Weg Umgebungsvariablen des Elternprozesses zu manipulieren?
MfG
bubble
Da allerdings das Script seinen eigenen Scope hat, wirkt sich das nicht auf das Terminalfenster aus. Und ein
export PATH=$PATH:${DIR}gilt ja auch nur für Kindprozesse.
DIR ist hierbei der aufgelöste absolute Pfad zum Verzeichnis des Scripts.
MfG
bubble
Tach!
Was ich aus einer zweistündigen Google-Sitzung in Erfahrung gebracht habe, ist das jeder Terminal seinen eigenen Scope bekommt, so wie jeder Kindprozess.
Lange Rede, kurzer Sinn: Gibt es einen Weg Umgebungsvariablen des Elternprozesses zu manipulieren?
Nach zwei Stunden Nase voll von Google? http://stackoverflow.com/questions/263005/is-it-possible-to-change-the-environment-of-a-parent-process-in-python
dedlfix.
Tach!
Nach zwei Stunden Nase voll von Google? http://stackoverflow.com/questions/263005/is-it-possible-to-change-the-environment-of-a-parent-process-in-python
Auf die Seite bin ich auch schon gestoßen, dachte aber, da gibt es vielleicht doch noch was besseres als noch eine andere Sprache mit ins Spiel zu bringen. Alles in allem imho zu viel over head nur um ein "./" zu umgehen :s
MfG
bubble
Tach!
Nach zwei Stunden Nase voll von Google? http://stackoverflow.com/questions/263005/is-it-possible-to-change-the-environment-of-a-parent-process-in-python
Auf die Seite bin ich auch schon gestoßen, dachte aber, da gibt es vielleicht doch noch was besseres als noch eine andere Sprache mit ins Spiel zu bringen.
Du brauchst keine neue Sprache. Der Fragende dort hatte nur zufällig das Problem mit einem Python-Programm. Aber das funktioniert mit jedem anderen Programm genauso - also auch mit einem Shell-Script. "source" (oder einfach ein alleinstehender . mit Leerzeichen danach) schon probiert? Das startet das angegebene Programm/Shellscript in der aktuellen Shell und baut keine neue Umgebung auf.
dedlfix.
Du brauchst keine neue Sprache. Der Fragende dort hatte nur zufällig das Problem mit einem Python-Programm. Aber das funktioniert mit jedem anderen Programm genauso - also auch mit einem Shell-Script. "source" (oder einfach ein alleinstehender . mit Leerzeichen danach) schon probiert? Das startet das angegebene Programm/Shellscript in der aktuellen Shell und baut keine neue Umgebung auf.
Hm, das hab ich dann grundlegend falsch verstanden :'D
MfG
bubble
Ich würde es gerne ermöglichen, dass man einfach einmal nur etwas wie
~/bin/botmgr --tmpregistereingeben muss und das Script PATH ändert.
Du willst (trotz aller Sicherheitsbedenken) das aktuelle Verzeichnis temporär in den Pfad der aktuellen Shell aufnehmen? Per Skript?
OK.
Dein ~/bin/botmgr:
------------------------
export PATH="$PATH:."
------------------------
Keine shebang!
Ausführen mit
. botmgr (siehe Dedlfix)
(bei mir ist ~/bin im Pfad) - Danach ist der Pfad in der aktuellen Shell gesetzt und auch in Subshells gültig. (Ausnahme folgt)
Warnung: Fummel damit nie(NIE!) als root herum. (Ich bin sehr froh, dass diese Variable bei einem "sudo bash" nicht "überlebt".
Du willst (trotz aller Sicherheitsbedenken) das aktuelle Verzeichnis temporär in den Pfad der aktuellen Shell aufnehmen? Per Skript?
Nicht das aktuelle, sondern das, in dem sich das Script befindet. In dem Verzeichnis befinden sich sont nur PHP-Dateien, die kein execute-Flag haben. Allerdings bin ich mir momentan nicht wirklich der Sicherheitsbedenken bewusst, welche wären das denn?
Dein ~/bin/botmgr:
export PATH="$PATH:."Keine shebang!
Dadurch das ich nur über den einen Befehl gesprochen hab, hab ich alle sonstigen Zeilen inklusive shebang weggelassen. Ich will hier kein 500 Zeilen-Script posten wo 99% nichts damit zu tun haben. Und da ich im Thema "bash" als erstes erwähnt habe, dachte ich [code=sh]#!/bin/bash[/code] wäre klar.
Ausführen mit
. botmgr (siehe Dedlfix)
(bei mir ist ~/bin im Pfad) - Danach ist der Pfad in der aktuellen Shell gesetzt und auch in Subshells gültig. (Ausnahme folgt)
Warnung: Fummel damit nie(NIE!) als root herum. (Ich bin sehr froh, dass diese Variable bei einem "sudo bash" nicht "überlebt".
Warum? Das ist doch nach wie vor nur temporär, nur ein ausführbares Script (sprich mit execute-Flag) kann darüber direkt angesteuert werden.
MfG
bubble
Du willst (trotz aller Sicherheitsbedenken) das aktuelle Verzeichnis temporär in den Pfad der aktuellen Shell aufnehmen? Per Skript?
... Allerdings bin ich mir momentan nicht wirklich der Sicherheitsbedenken bewusst, welche wären das denn?
Ganz einfaches Beispiel: (Nicht testen)
Jemand, z.B. der Ubuntu-Gast (Linux ist ein Mehrbenutzersystem) schreibt nebst einer shebang "rm -rf /*" nach /tmp/wget und vergibt jedem das Recht zu lesen und auszuführen. wget sei entweder nicht installiert oder der Künstler namens root hat den aktuellen Ordner sogar als ersten Eintrag im Pfad. (export PATH=".:$PATH")
Root meint mal was testen zu müssen (# wget sonstwas) und macht, ohne das zu wollen, das System platt.
Dein ~/bin/botmgr:
export PATH="$PATH:."Keine shebang!
Und da ich im Thema "bash" als erstes erwähnt habe, dachte ich#!/bin/bashwäre klar.
Hast Du falsch verstanden. Du SOLLST in diesem Fall keine shebang eintragen, damit wirklich die aktuelle Shell den befehl ausführt.
Jemand, z.B. der Ubuntu-Gast (Linux ist ein Mehrbenutzersystem) schreibt nebst einer shebang "rm -rf /*" nach /tmp/wget und vergibt jedem das Recht zu lesen und auszuführen. wget sei entweder nicht installiert oder der Künstler namens root hat den aktuellen Ordner sogar als ersten Eintrag im Pfad. (export PATH=".:$PATH")
Root meint mal was testen zu müssen (# wget sonstwas) und macht, ohne das zu wollen, das System platt.
Klingt schlüssig, wäre ich aber wohl nie selbst drauf gekommen, weil ich nicht dran gedacht habe, dass man seinen Pfad ja auch vorn ran stellen kann :s
Dein ~/bin/botmgr:
export PATH="$PATH:."Keine shebang!
Und da ich im Thema "bash" als erstes erwähnt habe, dachte ich#!/bin/bashwäre klar.Hast Du falsch verstanden. Du SOLLST in diesem Fall keine shebang eintragen, damit wirklich die aktuelle Shell den befehl ausführt.
Ouh. Okay, dann will ich nichts gesagt haben :'D
Hrm. Ich glaub ich lass die Funktion raus, bis ich wirklich weiß, was ich damit an Schaden anrichten kann.
MfG
bubble
Hallo,
Hast Du falsch verstanden. Du SOLLST in diesem Fall keine shebang eintragen, damit wirklich die aktuelle Shell den befehl ausführt.
auf die Gefahr hin, dass ich als Ahnungsloser auffalle ...
Dann wäre doch die logische Konsequenz, dass man die shebang-Zeile generell weglassen sollte, denn es ist doch eher der Regelfall, dass die aktuelle Shell das Script ausführen soll. Wenn ich eine neue (oder gezielt eine ganz bestimmte) Shell haben will, dann starte ich die explizit.
Oder was habe ich da falsch verstanden?
So long,
Martin (der auch unter Linux seine Batchdateien immer ohne shebang schreibt)
Tach!
Hast Du falsch verstanden. Du SOLLST in diesem Fall keine shebang eintragen, damit wirklich die aktuelle Shell den befehl ausführt.
Dann wäre doch die logische Konsequenz, dass man die shebang-Zeile generell weglassen sollte,
Nein. Das wäre nur für sehr einfache und wirklich nur Shellscripts sinnvoll. Die Shebang braucht es nicht nur, um für Nicht-Shell-Scripte (also Perl, Phython, Ruby, Expect, ...) die passende Laufzeitumgebung zu finden. Auch Shells gibt es wie Sand am Meer, inklusive deren Dialekte.
denn es ist doch eher der Regelfall, dass die aktuelle Shell das Script ausführen soll.
Ist es das? Wann genau braucht man denn wirklich die aktuelle Umgebung? In wieviel Prozent der Fälle reicht eine Kopie nicht mehr? Und wenn das "sehr viele" wären, warum ist das noch niemandem aufgefallen und hat einen Umstellungsversuch unternommen?
Wenn ich eine neue (oder gezielt eine ganz bestimmte) Shell haben will, dann starte ich die explizit.
Das ist umständlich und wird auch nicht besser, wenn du Parameter brauchst, die ansonsten in der Shabang notiert sind.
dedlfix.
Hallo,
Dann wäre doch die logische Konsequenz, dass man die shebang-Zeile generell weglassen sollte,
Nein. Das wäre nur für sehr einfache und wirklich nur Shellscripts sinnvoll.
nur darauf hatte ich mich auch bezogen.
Die Shebang braucht es nicht nur, um für Nicht-Shell-Scripte (also Perl, Phython, Ruby, Expect, ...) die passende Laufzeitumgebung zu finden.
Hm. Dagegen war ja die Erkennung nach der Windows-Methode an der Dateiendung ein richtiger Fortschritt. Denn das für die Laufzeitumgebung notwendige Programm kann ja von System zu System in verschiedenen Verzeichnissen liegen, es ist also problematisch, das im Kopf jedes Scripts festzuschreiben.
denn es ist doch eher der Regelfall, dass die aktuelle Shell das Script ausführen soll.
Ist es das? Wann genau braucht man denn wirklich die aktuelle Umgebung?
Gegenfrage: In wie vielen Fällen ist denn das Environment überhaupt von Belang? Offensichtlich gibt es solche Fälle, wie dieser Thread zeigt. Aber ist es nicht so, dass man sich in den allermeisten Fällen "keinen Kopp" macht, weil es irrelevant ist? Ist es deshalb nicht ein unnötiger Overhead, wenn für jeden Aufruf einer Batchdatei eine neue Shell-Instanz gestartet wird?
Wenn ich eine neue (oder gezielt eine ganz bestimmte) Shell haben will, dann starte ich die explizit.
Das ist umständlich ...
Ansichtssache. Ich halte das nicht für umständlich, sondern für gewissenhaft. Ich vertrete die Ansicht, dass ich meinem PC ausdrücklich sage, was er zu tun hat, und ich möchte im Normalfall nicht, dass durch irgendeine Magie etwas darüber hinaus läuft (das ist mit ein Grund, warum ich Windows den Rücken gekehrt habe).
Ciao,
Martin
Tach!
Dann wäre doch die logische Konsequenz, dass man die shebang-Zeile generell weglassen sollte,
Nein. Das wäre nur für sehr einfache und wirklich nur Shellscripts sinnvoll.
nur darauf hatte ich mich auch bezogen.
Das hatte ich schon vermutet, aber mir war das noch nicht ganz eindeutig.
Die Shebang braucht es nicht nur, um für Nicht-Shell-Scripte (also Perl, Phython, Ruby, Expect, ...) die passende Laufzeitumgebung zu finden.
Hm. Dagegen war ja die Erkennung nach der Windows-Methode an der Dateiendung ein richtiger Fortschritt. Denn das für die Laufzeitumgebung notwendige Programm kann ja von System zu System in verschiedenen Verzeichnissen liegen, es ist also problematisch, das im Kopf jedes Scripts festzuschreiben.
Dafür/dagegen gibt es ja /usr/bin/env
Gegenfrage: In wie vielen Fällen ist denn das Environment überhaupt von Belang? Offensichtlich gibt es solche Fälle, wie dieser Thread zeigt. Aber ist es nicht so, dass man sich in den allermeisten Fällen "keinen Kopp" macht, weil es irrelevant ist? Ist es deshalb nicht ein unnötiger Overhead, wenn für jeden Aufruf einer Batchdatei eine neue Shell-Instanz gestartet wird?
Genauso könntest du ja - um mal zu übertreiben - für eine Sandbox plädieren. Meist braucht man die nicht, also kann man die ja generell beim Start von Programmen/Scripten/Dokumenten links liegen lassen und nur wenn man was wirklich verdächtiges starten/öffnen will, dann nimmt man sie. Nur, wer prüft das denn jedes Mal vorher, ob ein Programm keinen Unfug anstellt? Wer prüft denn, dass das Script die Shell genauso wieder verlässt, wie es sie vorgefunden hatte und kein Unrat liegen bleibt?
dedlfix.
Hallo,
Dagegen war ja die Erkennung nach der Windows-Methode an der Dateiendung ein richtiger Fortschritt. Denn das für die Laufzeitumgebung notwendige Programm kann ja von System zu System in verschiedenen Verzeichnissen liegen, es ist also problematisch, das im Kopf jedes Scripts festzuschreiben.
Dafür/dagegen gibt es ja /usr/bin/env
könntest du den Zusammenhang etwas näher erläutern? Ich kannte das noch nicht und habe mir mit 'env --help' erstmal eine Kurzinfo geben lassen. Wenn ich es richtig verstehe, kann ich damit ein anderes Programm starten und diesem ein gezielt geändertes Environment mitgeben. Okay.
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?
Genauso könntest du ja - um mal zu übertreiben - für eine Sandbox plädieren. Meist braucht man die nicht, also kann man die ja generell beim Start von Programmen/Scripten/Dokumenten links liegen lassen und nur wenn man was wirklich verdächtiges starten/öffnen will, dann nimmt man sie.
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. Nur bei Software, die über die Paketquellen meiner Distro bereitgestellt wird, bin ich mal vertrauensselig; da gehe ich davon aus, dass das von der betreuenden Community entsprechend geprüft wird.
Nur, wer prüft das denn jedes Mal vorher, ob ein Programm keinen Unfug anstellt? Wer prüft denn, dass das Script die Shell genauso wieder verlässt, wie es sie vorgefunden hatte und kein Unrat liegen bleibt?
Was für Unrat meinst du? Geänderte Environment-Einträge? Ich sag's mal so: WENN ein Script das Environment ändert, dann hat das doch normalerweise einen Sinn. Und dann ist es doch erwünscht, dass diese Änderungen auch für weitere Script- oder Programmaufrufe erhalten bleiben.
So long,
Martin
Tach!
Denn das für die Laufzeitumgebung notwendige Programm kann ja von System zu System in verschiedenen Verzeichnissen liegen, es ist also problematisch, das im Kopf jedes Scripts festzuschreiben.
Dafür/dagegen gibt es ja /usr/bin/env
könntest du den Zusammenhang etwas näher erläutern? [...] Wenn ich es richtig verstehe, kann ich damit ein anderes Programm starten und diesem ein gezielt geändertes Environment mitgeben. Okay. 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.
Genauso könntest du ja - um mal zu übertreiben - für eine Sandbox plädieren. Meist braucht man die nicht, also kann man die ja generell beim Start von Programmen/Scripten/Dokumenten links liegen lassen und nur wenn man was wirklich verdächtiges starten/öffnen will, dann nimmt man sie.
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.
Nur, wer prüft das denn jedes Mal vorher, ob ein Programm keinen Unfug anstellt? Wer prüft denn, dass das Script die Shell genauso wieder verlässt, wie es sie vorgefunden hatte und kein Unrat liegen bleibt?
Was für Unrat meinst du? 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? Oft geht es nur darum, den Kindprozessen eine gewünschte Umgebung bereitzustellen. Es ist aufwendiger am Ende (nebst unvorhergesehenem Abbruch) alles zu Fuß aufzuräumen. Einfacher, effektiver und effizienter ist es, die benutzte Umgebung einfach komplett zu entsorgen.
dedlfix.
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
Tach!
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.
Das würde ich jetzt nicht so statistisch sicher behaupten wollen. Meiner unmaßgeblichen Beobachtung nach wird env immer bekannter und ist häufiger anzutreffen.
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.
Also ich habe sehr selten Bedarf, ein Script mit source beziehungsweise . starten zu müssen, um es in der aktuellen Shell zu halten. Die meisten Shellscripts kommen sehr gut in abgeschirmten Umgebungen zurecht, und sind sogar auch darauf ausgelegt. Sie haben ja keine andere Chance, variable Werte anderswo als in Umgebungsvariablen abzulegen[*]. Es ist wesentlich wichtiger, dass man nicht ständig im Script prüfen muss, ob Variablen übergeordneter Prozesse beeinträchtigen werden und auf das Aufräumen achten muss.
[*] also nicht dass ich wüsste. (Dateien mal außen vor gelassen.)
dedlfix.
Hi,
Die meisten Shellscripts kommen sehr gut in abgeschirmten Umgebungen zurecht, und sind sogar auch darauf ausgelegt. Sie haben ja keine andere Chance, variable Werte anderswo als in Umgebungsvariablen abzulegen[*].
ja klar, es gibt sicher unzählige Fälle, wo ein Script in einer abgeschirmten Umgebung laufen kann, vielleicht ist das sogar die Mehrheit. Aber ist es so ungewöhnlich, dass Script A Voraussetzungen prüft, Defaults setzt, dann endet und dem Anwender die Chance gibt, interaktiv weitere Parameter zu setzen oder Bearbeitungsschritte zu starten, um schließlich Script B aufzurufen, das aus allen bisher gesetzten Umgebungsvariablen (und weiteren Informationen, z.B. vorhandene oder nicht vorhandene Dateien und/oder Kommandozeilenparameter) die eigentliche Arbeit zu erledigen?
Also ich hatte in meiner aktiven Windows-Zeit schon unzählige Male den Wunsch, dass das möglich wäre. In der Linux-Welt fehlt mir noch etwas Erfahrung und Routine, aber es könnte auf dasselbe hinauslaufen.
Ciao,
Martin
Tach!
Aber ist es so ungewöhnlich, dass Script A Voraussetzungen prüft, Defaults setzt, dann endet und dem Anwender die Chance gibt, interaktiv weitere Parameter zu setzen oder Bearbeitungsschritte zu starten, um schließlich Script B aufzurufen, das aus allen bisher gesetzten Umgebungsvariablen (und weiteren Informationen, z.B. vorhandene oder nicht vorhandene Dateien und/oder Kommandozeilenparameter) die eigentliche Arbeit zu erledigen?
Meines Erachtens ja, weil unter Unix in der Regel die Datenübergabe über stdout nach stdin erfolgt. Mir fällt grad kein Fall ein, bei dem ich Datenübergabe in Variablen für mehr als nur das Setzen von Konfigurationswerten gesehen habe.
dedlfix.