![Kann ich ein Shebang verwenden, um eine Dateiquelle selbst in die aktuelle Bash-Umgebung zu integrieren?](https://rvso.com/image/89150/Kann%20ich%20ein%20Shebang%20verwenden%2C%20um%20eine%20Dateiquelle%20selbst%20in%20die%20aktuelle%20Bash-Umgebung%20zu%20integrieren%3F.png)
Ich habe eine wachsende Sammlung vonSkriptewelchesollte bezogen und nicht ausgeführt werden. Im Moment haben sie den Kram
#! /bin/cat
aber ich würde es vorziehen, wenn sie beim Ausführen in Bash eingebunden würden, so wie ich es getan habe
$ . /path/to/script.sh
oder
$ source /path/to/script.sh
Aber .
sind source
Bash-Funktionen integriert, ist also eine alternative Shebang-Zeile für solche Skripte möglich?
Antwort1
Nein. Wenn ein Shebang ins Spiel kommt, haben Sie bereits verloren. Ein Shebang wird angewendet, wenn ein Prozess ausgeführt wird, exec()
und das geschieht normalerweise nach dem Forking, sodass Sie sich bereits in einem separaten Prozess befinden. Es ist nicht die Shell, die den Shebang liest, sondern der Kernel.
Antwort2
Der She-Bang wird bei der Ausführung eines Befehls vom Kernel interpretiert, nicht von der Shell. Zu diesem Zeitpunkt ist es also zu spät.
Sie können es stattdessen machen:
#! /bin/echo Please run (from a Bourne-like shell): .
Oder:
#! /bin/sed 2,5!d;s/^#.//
# This script must be sourced from within a shell
# and not executed. For instance with:
#
# . path/to/that/script
rest of the script
Um dem Benutzer mitzuteilen, was er falsch gemacht hat.
Das sollte unter Linux funktionieren. Ersetzen Sie bei einigen anderen Betriebssystemen alle Leerzeichen außer dem ersten durch eines der nicht-ASCII-Zeichen (wie U+00A0, U+2006...). Möglicherweise müssen Sie den Pfad der echo
oder sed
Dienstprogramme anpassen.
Antwort3
Wie der Benutzer @muru sagt, ist dies nicht möglich, da Sie die Shell-Sitzung bereits verlassen haben, wenn Sie zur #!
-Zeile gelangen.
Abhängig von der Funktion Ihrer Shell-Dateien kann es jedoch möglicherweise eine andere Lösung geben.
Ich vermute, dass sie Umgebungsvariablen festlegen, die Sie für ein Projekt verwenden.
Nennen wir ein Projekt subtool
(weil ich ein solches Projekt habe). Dann könnten Sie ein Skript haben, das eine Shell-Umgebung für Projekte einrichtet, project-env
zum Beispiel:
#!/bin/bash
PROJECT="$1"
PROJECT_ROOT="$HOME/projects/$PROJECT"
cd "$PROJECT_ROOT" || exit 1
source "$PROJECT.env"
export PS1="[$PROJECT: \W] \$ "
exec bash -i
Ausführen mit:
$ ./project-env subtool
Dadurch wird automatisch cd
der angegebene Projektunterordner darunter geöffnet $HOME/projects
, eine Projektumgebungsdatei namens gelesen subtool.env
(in diesem Fall) (in der Sie Variablen initialisieren), Sie erhalten eine Eingabeaufforderung für die Eingabeaufforderung für das Projekt und verlassen eine interaktive bash
Sitzung:
[subtool: subtool] $
Wenn Ihre Arbeit erledigt ist, einfach exit
.
Dies hat außerdem den Vorteil, dass die Projektumgebung von Ihrer „normalen“ Shell-Anmeldesitzung und von anderen Projekten isoliert wird.
Antwort4
Die Dinge, die Sie in diesen .'ed-Skripten tun möchten, ändern den Shell-Prozess. Sie müssen sie also vom Shell-Prozess aus aufrufen. Das bedeutet entweder Aliase oder ihre mächtigeren Brüder, die Shell-Funktionen. Das bedeutet, dass Sie einige Einstellungen in .profile oder Ähnlichem vornehmen müssen.
Der Alias-Trick ist ziemlich simpel: alias mytool1=". /my/library/mytool1.sh"
Kannst du am Anfang alles einlesen? .profile: . /my/library/define_tools.sh
define_mytools.sh: mytool1() { ... Inhalt von mytool1.sh ... } mytool2() { ...; }