Kann ich ein Shebang verwenden, um eine Dateiquelle selbst in die aktuelle Bash-Umgebung zu integrieren?

Kann ich ein Shebang verwenden, um eine Dateiquelle selbst in die aktuelle Bash-Umgebung zu integrieren?

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 sourceBash-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 echooder sedDienstprogramme 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-envzum 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 cdder 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 bashSitzung:

[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() { ...; }

verwandte Informationen