Shebangs global overrulen

[shevegen]

Hallo, vielleicht weiss ja einer von euch Bescheid.

Angenommen ich hab einen Shebang-Pfad in einer Datei
#/usr/local/bin/ruby

und eine weitere Datei hat

#/usr/bin/env ruby

So. Angenommen beide stimmen nicht, dann kann diese Datei nicht ausgeführt werden.

Gibt es einen globalen Weg eine Aktion durchzuführen wenn shebangs nicht funktionieren?

Quasi so etwas wie:
"on error use this path instead:
/opt/bin/ruby"

Falls es notwendig ist erläutere ich genauer was ich brauche oder gerne hätte.

[Methusalix]

Hallo,

zum Sachverhalt mal folgendes: Deine erste Variante ist ja gebräuchlich und setzt voraus,
das der Interpreter auch genau in dem Pfad gefunden wird.

Die zweite Variante mit dem "env" wird ja für die Fälle benutzt, bei denen
der Pfad zum Interpreter unklar oder unbekannt ist. In diesem Fall sucht das Programm "env" in der PATH-Umgebungsvariable nach, wo der Interpreter steckt.

Falls der Interpreter auch dann nicht gefunden wird, liegt meiner Meinung nach eh ein Problem oder eine ungewöhnliche Installation / Konfiguration vor. Dann könnte der letzte Satz aus Deinem Post hilfreich sein.

Davon abgesehen kannst Du natürlich mit den üblichen Suchmechanismen den Interpreter erstmal
lokalisieren und in einem Script auswerten. Schreib mal noch ein bißchen mehr zu Deinen Absichten...

Gruß M.

[GoKi]

env generiert eine Fehlermeldung, wenn es das binary nicht finden kann.

Quasi so etwas wie:
"on error use this path instead:
/opt/bin/ruby"

Falls env dann im Nachhinein den richtigen Pfad für ruby anzeigen soll, dann hätte es ruby auch gleich starten können... Henne-Ei-Problem

[Meillo]

Dir wird nur übrig bleiben env und den Kernel (bei Linux: [0]) zu hacken.

Aber wann willst du denn diese Meldung ausgeben lassen? Immer wenn der Shebang fehlschlägt? Immer dann wenn der String ``ruby'' im Shebang enthalten ist?

Nimm lieber /opt/bin in PATH auf, dann können die User bei kaputtem Shebang selbst

Code: Alles auswählen

ruby /path/to/script

aufrufen.


[0] http://git.kernel.org/?p=linux/kernel/g ... 7a;hb=HEAD

[shevegen]

Hallo!

Sorry für die späte Antwort, ich habe das Thread in meiner Todo-Liste abgelegt - quasi, wenn ich herausfinden kann wie ich dieses Problem löse, sehr gut. Und danke an euch alle die behilflich sind! Es ist aber auch nicht besonders schlimm wenn ich es nicht lösen kann, daher gehe ich meine Todo Liste nur langsam durch.

Hier der Hintergrund:

Ich passe meine Distribution(en) immer sehr stark an meine Bedürfnisse an. Und die Bedürfnisse ändern sich immer wenn ich Ideen habe und diese ausprobieren möchte.

So kann es dann mal sein das /usr/bin/env einfach nicht mehr existiert - oder genau gesagt,
/usr/bin/env könnte auf einmal auf /opt/bin/env sein. Oder ganz wo anders. Und manchmal zerschiesse ich irgend etwas, dann geht einiges einige Zeitlang nicht mehr (Ja, chaotisch.)

Nun kann ich natürlich das ganze einfach mit Symlinks lösen.

Das wäre eine Möglichkeit. Aber ich würde das gerne ohne Symlinks lösen. Vor allem da ja symlinks auf dem Filesystem existieren müssen und manchmal existiert z. Bsp. /usr/bin bei mir nicht mehr. Da möchte ich dann auch nicht einfach irgendein Symlink erstellen.

Nimm lieber /opt/bin in PATH auf, dann können die User bei kaputtem Shebang selbst

Ja das wäre auch eine Möglichkeit. Ich möchte aber, komisch wie ich bin, meinen PATH ganz klein halten. Im Moment hat PATH nur einen Pfad Eintrag:

/sys/bin

Und falls shebangs fehl schlagen, möchte ich das sie automatisch dort reinschauen.

Was wäre da wohl die einfachste Möglichkeit? env hardcoded patchen in coreutils?

Ich denke, ich kann auch anders fragen.

Wie weiss der Kernel oder die Shell das man Shebangs ausführen möchte? Ist das in bash geschrieben oder so? Ich meine, ich weiss was die Shebangs machen aber ich weiss nicht wie sie das machen.

[MustrumRidcully]

schau mal in das alternatives-system: /etc/alternatives, /var/lib/dpkg/alternatives, und

Code: Alles auswählen

man update-alternatives

ich schätze, das ist es, was du suchst.

[uname]

Ich passe meine Distribution(en) immer sehr stark an meine Bedürfnisse an
So kann es dann mal sein das /usr/bin/env einfach nicht mehr existiert

Nicht schlecht. "env" gehört zu coreutils, könnte wichtig sein

und manchmal existiert z. Bsp. /usr/bin bei mir nicht mehr

Cool. Ist das System dann noch lauffähig? Reicht es wirklich dann ein paar PATH-Variablen zu erweitern, damit das System noch alles findet selbst vom Booten her? Noch besser wäre es wenn du es auch schaffen würdest /bin und /sbin zu verschieben.

[CH777]

Nur aus reinem Interesse: Welches "Bedürfnis" hast du denn, das zur Löschung/Verschiebung von /usr/bin führt?

[Liffi]

Nur aus reinem Interesse: Welches "Bedürfnis" hast du denn, das zur Löschung/Verschiebung von /usr/bin führt?

Vielleicht ist er bumblebee Nutzer.

[Meillo]

Ich passe meine Distribution(en) immer sehr stark an meine Bedürfnisse an. Und die Bedürfnisse ändern sich immer wenn ich Ideen habe und diese ausprobieren möchte.

So kann es dann mal sein das /usr/bin/env einfach nicht mehr existiert - oder genau gesagt,
/usr/bin/env könnte auf einmal auf /opt/bin/env sein. Oder ganz wo anders. Und manchmal zerschiesse ich irgend etwas, dann geht einiges einige Zeitlang nicht mehr (Ja, chaotisch.)

Wenn du diesen Weg gehst, dann musst du natuerlich auch einiges in Kauf nehmen.

Der Sinn an `/usr/bin/env' ist ja gerade, dass dieser Pfad auf jedem Unix gleich sein sollte.

Nun kann ich natürlich das ganze einfach mit Symlinks lösen.

Das ist wohl der sinnvollste Weg.

Das wäre eine Möglichkeit. Aber ich würde das gerne ohne Symlinks lösen. Vor allem da ja symlinks auf dem Filesystem existieren müssen und manchmal existiert z. Bsp. /usr/bin bei mir nicht mehr. Da möchte ich dann auch nicht einfach irgendein Symlink erstellen.

Wenn dein env(1) woanders liegt, dann lass doch automatisiert in allen Scripten auf deinem System den Pfad in der Shebangzeile aendern. Dazu haben wir doch eine programmierbare Shell. Wenn du deine Filesystemhierarchy anpasst, dann musst du folglich auch deine Programme anpassen.

Und falls shebangs fehl schlagen, möchte ich das sie automatisch dort reinschauen.

So formuliert musst du den Kernel hacken. Aber vermutlich meintest du: ``Wenn env(1) nichts in $PATH findet, dann soll es auch noch in /sys/bin suchen.'' Das ist ja gerade der Sinn von $PATH; es gibt die Variable weil man genau dieses Problem loesen wollte. ... aber man kann das Rad natuerlich auch immer wieder neu erfinden.

Was wäre da wohl die einfachste Möglichkeit?

$PATH so zu verwenden wie es gedacht ist.

env hardcoded patchen in coreutils?

Ja, so koenntest du es machen.

Wie weiss der Kernel oder die Shell das man Shebangs ausführen möchte?

Du rufst eine ausfuehrbare Datei auf -> Die Shell sagt dem Kernel: ``fuehre das aus!'' -> Der Kernel stellt fest, dass es kein bekanntes binaeres Programmformat ist, dafuer aber ein Shebang-Script. Folglich fuehrt er es als Shebangscript aus. Wie das genau ablaeuft steht im Quellcode (siehe Link in meinem frueheren Post).

Ich meine, ich weiss was die Shebangs machen aber ich weiss nicht wie sie das machen.

Quellcode lesen!

Oder Dokumentation lesen. Hier eine Auswahl (damit du dich nicht selbst bemuehen musst die Suchmaschine anzuwerfen):
http://marmaro.de/docs/freiesmagazin/shebang/
http://uninformativ.de/?section=news&nd ... newsid=110
http://www.in-ulm.de/~mascheck/various/shebang/


@MustrumRidcully: Alternatives will er nicht weil das waeren ja Symlinks ... und nicht nur einer sondern mindestens zwei.