nicht angemeldet
Hi,
Ich habe ein Problem. In einem Skript (usb.agent, für USB-Hotplugging), das vom Kernel-Hotplug-Dämon angestossen wird, habe ich einen Fehler entdeckt; dort steht irgendwo
if ! lsmod | grep -q "^$MODULE"; then
...
fiDas 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.
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[*]}
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(?). 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.
Wie kann das sein? Ist in System-Skripten STDOUT immer geschlossen?
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.
Nichtsdestotrotz: das scheint mir eine Aneinanderreihung von Unsauberkeiten zu sein, die hier einen Bug ergeben.
Aber ich würde mir da keinen Kopf machen, sondern einfach obige Vorschläge einmal durchprobieren und wenn es immer noch nicht klappt das ganze Script hier verlinken, dann steckt der Fehler höchstwahrscheinlich in einem anderem Detail.
so short
Christoph Zurnieden