Heute bin ich über eine recht seltsame Eigenheit von /usr/bin/grep unter Solaris (9 und 10, Sparc) gestolpert: Wenn sich in einem Unterverzeichnis
bla Dateien mit zehn Zeichen langen Dateinamen befinden (z.B.
blubbblubb) und man nach Teilen eines dieser Namen grept dann passiert folgendes:
$ grep lubb bla
blubbblubb
$
Und ausserdem zermatscht es einem das Terminal, da noch Binärmüll mit ausgegeben wird.
Da ich erst einen Bug vermutete, hab ich erstmal gegoogelt und
die Sourcen studiert. Es findet tatsächlich keine Prüfung statt, ob es sich bei einem übergebenen Dateinamen um ein normales File oder ein Verzeichnis handelt. Das File wird einfach per
read(2) gelesen und ein gematchter String wird gnadenlos ausgegeben. Auf Solaris gibt es ja noch andere grep, also mal geschaut was die machen:
/usr/xpg4/bin/grep findet die matches ebenfalls nur, wenn die Dateinamen genau 10 Zeichen lang sind, gibt aber wenigstens keinen Binärmüll aus. Gnu-Grep, in Solaris unter
/usr/sfw/bin/ggrep zu finden, matcht ebenfalls, sagt aber nur
Binary file bla matches. Bei GNU-Grep gibt es ausserdem die Option
-d, mit der man das Verhalten beeinflussen kann.
Unter Linux ist das Verhalten anders, hier werden Verzeichnisse so oder so nicht berücksichtigt. Dies liegt daran, dass Verzeichnisse unter Linux nicht mit read(2) gelesen werden können.
Nun die interessante Frage: Wer hat recht? Antwort: Alle. Niemand. Denn liest man in der Posix-Spezifikation nach, so heisst es dort lapidar:
INPUT FILES
The input files shall be text files.
Die Lösung heisst also:
Ãœbergib grep keine Namen von Nicht-Text-Files und du hast kein undefiniertes Verhalten.
