(BASH) Kommandos mit Ausgabe schlagen in Skript fehl

[Bio]

Sup!

if ! lsmod | grep -q "^$MODULE"; then
...
fi

Das ergibt aber immer "true" (als würde das Modul nie geladen sein), und der Inhalt des ifs wird immer ausgeführt.

Das kann durchaus korrekt sein. Ist das Modul wirklich vor Ausführung des Script(teil)es nicht geladen? Ist $MODULE gefüllt? Nutze z.B. 'logger' oder 'echo' um das herauszubekommen.

Das Modul ist geladen und die Variable gesetzt, und wie hier:

Als Test habe ich folgendes ins Skript geschrieben:

echo "bla bla" | grep "bla" >/dev/null 2>&1
logger ${PIPESTATUS[*]}
echo "bla bla" | grep -q "bla"
logger ${PIPESTATUS[*]}

zu sehen kenne ich "logger" ;-)

Ersteres Kommand ergibt im Log 0 0 (beide Kommandos erfolgreich), zweiteres 0 2 (echo klappt, aber grep versagt mit System-Fehler)

Laut den <http://linuxreviews.org/beginner/abs-guide/en/a16609.html@titleBash Exitcodes> deutet es darauf hin, das dsa benutze grep ein Shellbuiltin ist(?).

Ne, ist es nicht. Nicht nur Shell-Builtins können einen Fehlercode 2 werfen.

Suche einmal nach bin/grep und gebe den so gefundenen Pfad ein. Es ist sowieso eine Unsitte sich in Scripten darauf zu verlassen, das das richtige Programm in $PATH ist _und_ auch wirklich das Programm und kein Shellbultin.

PATH ist richtig gesetzt und die Bash hat wirklich kein eingebautes grep.

Welches STDOUT meinst Du? bei jeder Programmausführung werden per Default drei Dateien geöffnet STDERR, STDIN und STDOUT. Die kann da Programm zwar wieder schließen, aber dazu gibt es gewöhnlich keinen Grund. Anders sieht das natürlich mit Shellbuiltins aus. Da pro Programm nur je _einmal_ diese drei Dateien geöffnet werden, funktioniert das bei den Pipes dann etwas anders.

Es kann nur ein STDOUT geben! ;-)
Es scheint tatsächlich so, als ob in manchen System-Skripten STDOUT geschlossen ist, man also Probleme bekommt, wenn man z.B. "echo" benutzt (weil es fehlschlägt) oder Kommandos, die Ausgaben machen und so gut programmiert sind, beim Fehlschlagen der Ausgabe mit Fehlercode abzubrechen.

Nichtsdestotrotz: das scheint mir eine Aneinanderreihung von Unsauberkeiten zu sein, die hier einen Bug ergeben.

Nein, es scheint so, als wäre allein die Ausgabe der Fehlergrund.
In der neuesten CVS-Version der hotplug-Skripte hat man jedenfalls genau diese Zeile ebenfalls mit >/dev/null 2>&1 versehen.

Gruesse,

Bio