Interpretieren von Fehlermeldungen

Question

In meinen Skripten habe ich eine Funktion namens messages. Ich habe sie in Linux Mint geschrieben und konnte sie problemlos ausführen. Als ich sie jedoch auf eine Debian-Buster-Station verschoben habe, kollidierte die Funktion mit /usr/bin/messages.

Ich habe ein Startskript, das das Skript aufruft messages:

Startskript

# call to messages script
. messages

Mitteilungen

messages() {
  # reformat the arguments and return them
}

später startup_script

messages "This is a message"

Welche wirft

./startup_script: line 35: .: /usr/bin/messages: cannot execute binary file
messages: could not open mailbox `/path/to/my/script/<string passed to my function>': No such file or directory

Ich erhalte also eine Reihe von Fehlermeldungen, die damit zusammenhängen, dass ich /usr/bin/messagesanstelle meiner Funktion aufgerufen werde.

Nach dem Hinzufügen type messages "This is a message"lautet die relevante Ausgabe:

messages is /usr/bin/messages

Ich habe die Möglichkeit, meine Funktion umzubenennen¹, aber vielleicht gibt es eine bessere Möglichkeit, mit dieser Situation umzugehen.

Wie weise ich mein Skript an, Systembinärdateien zu ignorieren und meine eigenen Funktionen zu verwenden?

---

^{¹ Die Funktion wird in mehreren Skripten mehrmals aufgerufen, daher ist es nicht die einfachste Option, einfach den Namen zu ändern.}

Answer 1

So . filefunktioniert es:

Wenn filekein <Schrägstrich> enthalten ist, soll die Shell den durch angegebenen Suchpfad verwenden, PATHum das Verzeichnis zu finden, das die Datei enthält.

Dieses Verhalten istspezifiziert durch POSIX.

Ihr erster Fehler ist

./startup_script: line 35: .: /usr/bin/messages: cannot execute binary file

Ähnlich verhält es sich beim Aufruf von . echo:

-bash: .: /bin/echo: cannot execute binary file

Sie versuchen, die Binärdatei als Quelle zu verwenden /usr/bin/messages. Tatsächlich wird Ihre Datei, in der die Funktion definiert ist, überhaupt nicht als Quelle verwendet, da die Funktion im aktuellen Skript nicht definiert ist. Dies bedeutet, dass später messagesimmer noch bedeutet /usr/bin/messages, nicht die Funktion.

Die entsprechende Zeile sollte . ./messagesoder sein . /full/path/to/messages(also der Pfad zudeinDatei, nicht zur Binärdatei).

Answer 2

Interpretieren von Fehlermeldungen

Sehen Sie sich die Zeilennummer in der Fehlermeldung an. Auf diese Weise wissen Sie, in welcher Zeile der Fehler liegt. Das blieb uns verborgen, da Sie uns einige Zeilen aus einem Skript mit über 35 Zeilen gezeigt haben.

Welche Datei wird ausgeführt.

Wenn Sie eine Datei mit . file-to-sourceoder angeben file-to-run, werden die in der Umgebungsvariable aufgeführten Verzeichnisse $PATHvon links nach rechts durchsucht. Das aktuelle Verzeichnis ist nicht in dieser Liste enthalten, da dies ein Sicherheitsrisiko darstellen oder zumindest Verwirrung stiften kann. Wenn Sie ein Programm im aktuellen Verzeichnis ausführen möchten, müssen Sie angeben, dass es sich im aktuellen Verzeichnis befindet. z. B. . ./file-to-sourceoder ./file-to-run(Es ist nicht erforderlich, den vollständigen Pfad anzugeben).

Unixe hatten früher .im PATH, bis man erkannte, dass dies ein Problem darstellte. Beispielsweise wurde ein Programm lsim aktuellen Verzeichnis aufgerufen. CMD in Microsoft Windows hat immer noch .implizit im PATH, Sie können es nicht entfernen. Dies ist eine der Ursachen für eine hohe Anzahl an Malware-Infektionen unter diesem Betriebssystem.

Ein Haken

.bezieht sich auf das aktuelle Arbeitsverzeichnis, nicht auf das Verzeichnis, in dem sich das Skript befindet.

Um das zu lösen, kann so etwas getan werden.

(
   cd "$(dirname "$(readlink -f "$0")")"
   script_dir="$(pwd)"
)
script_dir/other_script

Hoffentlich kann jemand einen Link zu einer besseren Lösung bereitstellen.