Dalla man greppagina (su Debian):
DESCRIZIONE
grep searches the named input FILEs (or standard input if no files are
named, or if a single hyphen-minus (-) is given as file name) for lines
containing a match to the given PATTERN. By default, grep prints the
matching lines.
Nel primo caso, grepapre il file; nel secondo, la shell apre il file e lo assegna all'input standard di grep, e grepnon essendo passato alcun argomento sul nome del file presuppone che debba grep il suo input standard.
Pro di 1:
grep può grep più di un file¹.greppuò visualizzare il nome del file in cui si trova ogni occorrenza di line.
Pro di 2:
- Se il file non può essere aperto, la shell restituisce un errore che includerà informazioni più rilevanti (come il numero di riga nello script) e in modo più coerente (se si consente alla shell di aprire i file anche per altri comandi) rispetto a quando
greplo apre. E se il file non può essere aperto, grepnon viene nemmeno chiamato (che per alcuni comandi - forse no grep- può fare una grande differenza).
- in
grep line < in > out, se innon può essere aperto, outnon verrà creato o troncato.
- Non ci sono problemi con alcuni file con nomi insoliti (come
-o nomi di file che iniziano con -) ².
- cosmetico: puoi posizionarlo
<fileovunque sulla riga di comando per mostrare il flusso di comandi in modo più naturale, come <in grep line >outse preferissi.
cosmetico: con GNU grep, puoi scegliere quale etichetta usare davanti alla linea corrispondente anziché solo il nome del file come in:
<file grep --label='Found in file at line' -Hn line
In termini di prestazioni, se il file non può essere aperto, si salva l'esecuzione di grepquando si utilizza il reindirizzamento, ma per il resto grepnon mi aspetto molta differenza.
Con il reindirizzamento, risparmi di dover passare un argomento in più grep, rendi grepl'analisi dell'argomento leggermente più semplice. D'altra parte, la shell avrà bisogno (almeno) di una chiamata di sistema aggiuntiva al dup2()descrittore di file sul descrittore di file 0.
In { grep -m1 line; next command; } < file, grep(qui GNU grep) vorrà seek()tornare subito dopo la riga corrispondente in modo che next commandil resto del file sia visibile (dovrà anche determinare se il file è ricercabile o meno). In altre parole, la posizione all'interno di stdin è un'altra delle grepuscite. Con grep -m1 line file, può ottimizzarlo, è una cosa in meno grepdi cui preoccuparsi.
Gli appunti
¹ Con zsh, puoi fare:
grep line < file1 < file2
ma ciò equivale a cat file1 file2 | grep line(senza invocare l' catutilità) e quindi è meno efficiente, può causare confusione se il primo file non termina con un carattere di nuova riga e non ti farà sapere in quale file si trova il modello.
² Nel caso di ksh93e bash, tuttavia, ci sono file come /dev/tcp/host/port(e /dev/fd/xsu alcuni sistemi in bash) che, quando utilizzati nella destinazione dei reindirizzamenti, la shell intercetta per scopi speciali invece di aprire realmente il file sul file system (sebbene generalmente, quei file non esiste nel file system). /dev/stdinserve allo stesso scopo -riconosciuto grep, ma almeno qui è più propriamente spaziato (chiunque può creare un file chiamato -in qualsiasi directory, mentre solo gli amministratori possono creare un file chiamato /dev/tcp/host/porte gli amministratori dovrebbero conoscerlo meglio).