Ich untersuche gerade Debian-Pakete und habe einige Codebeispiele gelesen. Und in jeder Zeile zum Beispiel ist das postinstSkript ein Muster.
some command || true
another command || true
Wenn also ein Befehl fehlschlägt, gibt die Zeile true zurück, aber ich sehe nicht, wie sich dies auf die Ausgabe des Programms auswirkt.
Antworten:
Der Grund für dieses Muster ist, dass Betreuerskripte in Debian-Paketen in der Regel mit beginnen set -e, was dazu führt, dass die Shell beendet wird, sobald ein Befehl (genau genommen Pipeline-, Listen- oder Verbundbefehl) mit einem Nicht-Null-Status beendet wird. Dies stellt sicher, dass sich keine Fehler ansammeln: Sobald etwas schief geht, wird das Skript abgebrochen.
In Fällen, in denen ein Befehl im Skript fehlschlagen darf, wird durch das Hinzufügen || truesichergestellt, dass der resultierende zusammengesetzte Befehl immer mit dem Status Null beendet wird, sodass das Skript nicht abgebrochen wird. Das Entfernen eines Verzeichnisses sollte beispielsweise kein schwerwiegender Fehler sein (das Entfernen eines Pakets wird verhindert). also würden wir verwenden
rmdir ... || truesince rmdirhat keine Option, um anzugeben, dass Fehler ignoriert werden sollen.
set -ees überhaupt einer Notwendigkeit bedarf || true, hielt ich es für wichtig, den Kontext bereitzustellen. Wenn Sie auf POWER merkwürdige Dinge bemerken, empfehle ich Ihnen dringend, Bugs ( reportbug) einzureichen !
set -enicht nur eine "Debian-Konvention", sondern ein gutes Programmiermuster, das man immer verwenden sollte. Sehen. zB davidpashley.com/articles/writing-robust-shell-scripts
|| trueset -e verwendet wird ist der wahrscheinliche kontext und wahrscheinlich der häufigste. Ich verneige mich vor dieser Antwort! Buchstäblich ist es jedoch immer dann nützlich, wenn der Beendigungsstatus als irrelevant eingestuft wird UND (wie Sie durch den Artikellink hinzufügen) ich den Beendigungsstatus nicht als Teil meiner Skriptsteuerung verwende. Ich sehe utility (in set -e), würde aber nicht so weit gehen wie im Artikel und sagen "Jedes Skript, das Sie schreiben, sollte set -e oben einschließen". Es ist ein Programmierstil. "ALWAYS | Every" enthält einen eigenen Satz von Fallen - auch bekannt als - Absolutes Re: Wild-Card-Lösungen werden ALWAYSirgendwann nach hinten losgehen, auch bekannt als - keine kostenlosen Fahrten.
set -eVerhalten. Es mag Ihnen egal sein, ob Ihre einzigen Ziele bashund die anderen relativ neuen Shells sind, auf denen Sie leben /bin/sh, aber die Situation ist differenzierter, wenn Sie alte Shells / Systeme unterstützen möchten.
set -eVerhalten verschiedener Muscheln von Sven Mascheck dokumentiert , obwohl diese Seite auch viele historische / alte Muscheln dokumentiert, die heute irrelevant sind. Es gibt auch diese beiden Seiten mit einem schmaleren modernen Fokus (Suche nach "set -e"): "lintsh" -Seite , autoconfs Portable Shell-Dokumentation -> Seite zur Einschränkung von Builtins
Es hat zwar keine Auswirkung auf die Ausgabe des gerade ausgeführten Programms - es ermöglicht dem Aufrufer, fortzufahren, als ob alles in Ordnung wäre, was auch die zukünftige Logik betrifft.
Umformuliert: es Masken des Fehlerstatus des vorherigen Befehls.
michael@x071:[/usr/sbin]cat /tmp/false.sh
#!/bin/sh
false
michael@x071:[/usr/sbin]cat /tmp/true.sh
#!/bin/sh
false || true
michael@x071:[/usr/sbin]sh /tmp/false.sh; echo $?
1
michael@x071:[/usr/sbin]sh /tmp/true.sh; echo $?
0
set -eund der || trueNutzen wird durch die Merkmale und Ziele von definiert der Programmierer
git remote remove foo || true git remote add foo http://blah- Wir möchten den Fehler ignorieren, wenn die Fernbedienung nicht vorhanden ist.
||:ist eine andere idiomatische Art, dies zu schreiben (:ein weiterer Eintrag in der eingebauten Tabelle, der auf Bourne verweisttrue- aber garantiert auch auf Bourne; für POSIX shtrueist dies ebenfalls garantiert - also auf Bourne mehr Knappheit als Effizienz in selbst entfernt-modernen Zeiten).