"Whatis" gibt 0 für fehlende Befehle zurück

1

Unter MacOS 10.14 wird whatisein nicht installierter Befehl 'command': nothing appropriatewie erwartet gedruckt . Es wird jedoch 0 anstelle eines Fehlercodes zurückgegeben, der meines Erachtens das erwartete Verhalten darstellt. Es ist auch nicht konsistent mit man, was 1 zurückgibt, wenn keine Ergebnisse vorliegen. Darüber hinaus wird whatisauf stdout mangedruckt , während auf stderr gedruckt wird.

Dies unterscheidet sich von Linux, das einen Fehlercode zurückgibt und an stderr druckt.

Mac OS:

$ whatis abc; echo $?
abc: nothing appropriate
0

$ man abc; echo $?
No manual entry for abc
1

$ whatis abc 2>/dev/null
abc: nothing appropriate

$ man abc 2>/dev/null

Linux (Ubuntu):

$ whatis abc; echo $?
abc: nothing appropriate.
16

$ man abc; echo $?
No manual entry for abc
16

$ whatis abc 2>/dev/null

$ man abc 2>/dev/null

Ich glaube, whatissollte nicht 0 zurückgeben, wenn es keine Beschreibung des Befehls finden kann, und sollte ein Verhalten haben, das mit übereinstimmtman

Hinweis: Dies ist mir aufgefallen, weil ich ein Programm schreibe, das auf dieser Funktionalität basiert

Bearbeiten: aproposhat das gleiche Verhalten wiewhatis

Max Coplan
quelle

Antworten:

2

Unter macOS whatishandelt es sich nur um ein Shell-Skript.

$ type whatis
whatis is hashed (/usr/bin/whatis)
$ file /usr/bin/whatis
/usr/bin/whatis: POSIX shell script text executable, ASCII text

Wenn Sie nach innen schauen, lautet der entsprechende Teil

while [ "$1" != "" ]
do
    found=0
    for d in /var/cache/man $manpath /usr/lib
    do
        if [ -f $d/whatis ]
        then
            if grep -"$grepopt1" "$grepopt2""$1" $d/whatis
            then
                found=1
            fi
        fi
    done

    if [ $found = 0 ]
    then
        echo "$1: nothing appropriate"
    fi

    shift
done | eval ${PAGER:-more -E}

Wenn also keine Einträge gefunden werden (das if [ $found = 0 ]Teil), wird die Meldung angezeigt, ohne dass ein Beendigungscode festgelegt wurde. Tatsächlich wird das Skript nur mit dem Status 1 beendet, wenn falsche Argumente übergeben wurden.

Der letzte Update-Hinweis bezieht sich auf 2003-08-01das Datum des Updates, daher scheint er ohnehin ziemlich alt zu sein. Ob es sich bei dem Verhalten um eine Funktion oder einen Fehler handelt, kann diskutiert werden.


Für den Fall, dass Sie sich fragen, aproposob Sie dasselbe Verhalten zeigen aproposund whatisim Grunde dasselbe Skript verwenden.

$ ll /usr/bin/{apropos,whatis}
-r-xr-xr-x  1 root  wheel  1808 Aug 18 00:18 /usr/bin/apropos*
-r-xr-xr-x  1 root  wheel  1806 Aug 18 00:18 /usr/bin/whatis*
$ diff /usr/bin/{apropos,whatis}
26,27c26,27
< grepopt1=$aproposgrepopt1
< grepopt2=$aproposgrepopt2
---
> grepopt1=$whatisgrepopt1
> grepopt2=$whatisgrepopt2
nohillside
quelle
Danke. In Ubuntu whatisist es kompiliert, daher können wir keine ähnliche Analyse durchführen. Ich würde argumentieren, dass das Verhalten von macOS dem von Linux unterlegen ist. Es scheint klar, dass der Versuch, Informationen über einen nicht vorhandenen Befehl abzurufen, einen Fehler zurückgeben sollte. which abcgibt 1 zurück, man abcgibt 1 zurück usw. Obwohl dies whatisnicht Teil von POSIX ist, kann ich nicht sagen, dass Apples Implementierung "falsch" ist, aber ich sehe keine Vorteile darin, 0 zurückzugeben und auf stdout auszugeben.
Max Coplan
1
@MaxCoplan Möglicherweise ist es einfacher, bei Bedarf eine eigene Version zu erstellen.
Nohillside
1
Das habe ich gerade getan. Danke! Ihre Antwort lässt mich einfach whatisin meinen lokalen Papierkorb kopieren und dort bearbeiten.
Max Coplan
Ich habe eine Folgefrage an apple.stackexchange.com/questions/349920/…
Max Coplan,