Was bedeutet `{ { (exit 1); exit 1; }; }`?

Question

Ich habe den nächsten Codeausschnitt aus „ config.statusgeneriert von“ zitiert configure.

if test ! -f "$as_myself"; then
{ { echo "$as_me:$LINENO: error: cannot find myself; rerun with an absolute path" >&5
echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2;}
{ (exit 1); exit 1; }; }
fi

Was bedeutet „do“ im Codeausschnitt { (exit 1); exit 1; };? Welchen Zweck hat „doing“ nur exitin einer Subshell?

Answer 1

Die Ausführung (exit 1);ist die einfachste Möglichkeit, einen Trap auszulösen ERR. Wenn er aktiv ist, wird auch ein sofortiger Ausgang ausgelöst set -e. (Um den Fehlerzustand auszulösen, muss ein Befehl fehlschlagen; exitein Fehlerwert in einer Subshell führt dazu, dass die Subshell fehlschlägt.)

exit 1;wird keines von beidem tun.

{(exit 1); exit 1;}Kann also verwendet werden, um zunächst den ERRTrap zu erzeugen, der für Debugging-Zwecke hilfreich sein kann, und dann das Skript mit einer Fehleranzeige zu beenden.

Aber das ist nicht das, was in Dateien passiert autoconf. autoconfSkripte verlassen sich auf die EXITTrap, um temporäre Dateien zu bereinigen, die während der Ausführung erstellt wurden. Die meisten Shells, einschließlich, bashsetzen den Status aus dem im exitBefehl angegebenen Wert, bevor die EXITTrap aufgerufen wird. Dadurch kann die EXITTrap erkennen, ob sie aufgrund eines Fehlers oder einer normalen Beendigung aufgerufen wurde, und es kann auch sicherstellen, dass der Beendigungsstatus am Ende des Trap-Vorgangs korrekt festgelegt ist.

Allerdings scheinen einige Shells nicht zu kooperieren. Hier ist ein Zitat aus demautoconfHandbuch:

Einige Shell-Skripte, wie die von generierten autoconf, verwenden vor dem Beenden einen Trap zum Bereinigen. Wenn der letzte Shell-Befehl mit einem Status ungleich Null beendet wurde, wird auch der Trap mit einem Status ungleich Null beendet, sodass der Aufrufer erkennen kann, dass ein Fehler aufgetreten ist.

Leider ignoriert ein Exit-Trap in manchen Shells, wie z. B. Solaris /bin/sh, das Argument des Exit-Befehls. In diesen Shells kann ein Trap nicht feststellen, ob er durch einfaches Exit oder durch Exit 1 aufgerufen wurde. Anstatt exit direkt aufzurufen, verwenden Sie das AC_MSG_ERRORMakro, das einen Workaround für dieses Problem bietet.

Die Problemumgehung besteht darin, sicherzustellen, dass $?der Exit-StatusVorder exitBefehl wird ausgeführt, sodass er definitiv diesen Wert hat, wenn die EXITFalle ausgeführt wird. Und tatsächlich ist es das AC_MSG_ERRORMakro, das diesen merkwürdigen Code einfügt, komplett mit redundanten Klammern.

Answer 2

Dies hat meines Erachtens keinen Zweck, durch das Starten und sofortige Beenden einer Subshell lässt sich nichts direkt erreichen.

Solche Dinge sind höchstwahrscheinlich ein Nebeneffekt der automatischen Codegenerierung – in manchen Fällen werden in der Subshell möglicherweise andere Befehle ausgeführt, bei denen dies exit 1sinnvoll ist. Letztendlich besteht eine gute Chance, dass der Generierungscode irgendwie vereinfacht wird, indem er in manchen Fällen Anweisungen einfügen kann, die keine Funktion haben, und jedes Mal „sauberen Code“ zu generieren, ist komplexer. Entweder das oder der Code, der das Obige generiert hat, ist einfach schlecht geschrieben :)

Der großzügige Gebrauch von {...}ist ein weiteres Beispiel dafür. Die meisten von ihnen sind redundant, aber es ist einfacher, Code zu schreiben, der sie in jedem Fall einfügt (vielleicht möchten Sie in einigen Fällen die Ausgabe/Eingabe des Blocks umleiten), als diejenigen zu kennzeichnen, bei denen sie nicht benötigt werden, und sie wegzulassen.

Answer 3

(exit 1)ist ein einfacher, wahrscheinlich der einfachste Weg, einen bestimmten Exit-Code zu erhalten (im Spezialfall 1 gibt es natürlich einfachere Wege). Aber das ist in diesem Fall nicht der Grund, da der Exit-Code nicht untersucht wird.

Der Zweck des Einfügens exiteiner Subshell kann darin bestehen, das Skript nicht zu beenden (obwohl exit zum Generieren eines bestimmten Exit-Codes verwendet wird).