Dovrei preoccuparmi dei gatti non necessari?

Molte utility della riga di comando possono prendere il loro input da una pipe o come argomento del nome file. Per gli script di shell lunghe, trovo che iniziare la catena con un catrenda più leggibile, specialmente se il primo comando avrebbe bisogno di argomenti a più righe.

Confrontare

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

e

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

Quest'ultimo metodo è meno efficiente? In tal caso, la differenza è sufficiente a preoccuparsi se lo script viene eseguito, diciamo, una volta al secondo? La differenza nella leggibilità non è enorme.

La risposta "definitiva" è ovviamente fornita da The Useless Use of catAward .

Lo scopo di cat è di concatenare (o "catenare") i file. Se è solo un file, concatenarlo con niente è una perdita di tempo e ti costa un processo.

L'istanza di cat in modo che il tuo codice legga diversamente rende solo un altro processo e un altro set di flussi di input / output che non sono necessari. In genere, il vero ostacolo nei tuoi script sarà costituito da cicli inefficienti ed elaborazione effettiva. Sulla maggior parte dei sistemi moderni, un extra catnon ucciderà le tue prestazioni, ma c'è quasi sempre un altro modo per scrivere il tuo codice.

La maggior parte dei programmi, come notate, sono in grado di accettare un argomento per il file di input. Tuttavia, esiste sempre l'integrato della shell <che può essere utilizzato ovunque sia previsto un flusso STDIN che consente di salvare un processo eseguendo il lavoro nel processo della shell già in esecuzione.

Puoi persino essere creativo con DOVE lo scrivi. Normalmente verrebbe posto alla fine di un comando prima di specificare eventuali reindirizzamenti o pipe in questo modo:

sed s/blah/blaha/ < data | pipe

Ma non deve essere così. Può anche venire prima. Ad esempio il tuo codice di esempio potrebbe essere scritto in questo modo:

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

Se la leggibilità degli script è la tua preoccupazione e il tuo codice è abbastanza disordinato che l'aggiunta di una riga per catrendere più facile da seguire, ci sono altri modi per ripulire il codice. Uno che uso molto per aiutare gli script a capire facilmente in seguito è la suddivisione dei tubi in insiemi logici e il loro salvataggio in funzioni. Il codice dello script diventa quindi molto naturale e qualsiasi parte della pipeline è più facile da eseguire il debug.

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

È quindi possibile continuare con fix_blahs < data | fix_frogs | reorder | format_for_sql. Una pipeline che legge in questo modo è davvero facile da seguire e i singoli componenti possono essere facilmente sottoposti a debug nelle rispettive funzioni.

Ecco un riepilogo di alcuni degli svantaggi di:

cat $file | cmd

al di sopra di

< $file cmd

• Innanzitutto, una nota: mancano (intenzionalmente ai fini della discussione) le doppie virgolette mancanti $filesopra. Nel caso di cat, questo è sempre un problema tranne per zsh; nel caso del reindirizzamento, questo è solo un problema per bashoe ksh88per alcune altre shell solo quando interattivo (non negli script).
• Lo svantaggio più spesso citato è il processo aggiuntivo che viene generato. Nota che se cmdè incorporato, ci sono anche 2 processi in alcune shell come bash.
• Sempre dal punto di vista delle prestazioni, tranne che nelle shell in cui catè incorporato, viene eseguito anche un comando aggiuntivo (e ovviamente caricato e inizializzato (e anche le librerie a cui è collegato)).
• Sempre sul fronte delle prestazioni, per file di grandi dimensioni, che significa che il sistema dovrà pianificare il alternativamente cate cmdprocessi e costantemente riempire e svuotare il buffer tubo. Anche se cmdesegue chiamate di sistema di 1GBgrandi dimensioni read()alla volta, il controllo dovrà andare avanti e indietro tra cate cmdperché una pipe non può contenere più di pochi kilobyte di dati alla volta.
• Alcuni cmds (come wc -c) possono fare alcune ottimizzazioni quando il loro stdin è un file normale che non possono fare in cat | cmdquanto il loro stdin è solo una pipe allora. Con cate una pipe, significa anche che non possono seek()all'interno del file. Per comandi come taco tail, ciò fa un'enorme differenza nelle prestazioni in quanto ciò significa che con catessi è necessario memorizzare l'intero input in memoria.
• La cat $file, e anche la sua versione più corretta cat -- "$file", non funzionerà correttamente per alcuni nomi di file specifici come -(o --helpo qualsiasi altra cosa che inizi -se si dimentica --). Se uno insiste sull'uso cat, probabilmente dovrebbe usare cat < "$file" | cmdinvece per affidabilità.
• Se $filenon può essere aperto per la lettura (accesso negato, non esiste ...), < "$file" cmdsegnalerà un messaggio di errore coerente (dalla shell) e non verrà eseguito cmd, mentre cat $file | cmdverrà comunque eseguito cmdma con lo stdin che sembra un file vuoto. Ciò significa anche che in cose del genere < file cmd > file2, file2non filepuò essere ostruito se non può essere aperto.

Mettere <filealla fine di una pipeline è meno leggibile che avere cat fileall'inizio. L'inglese naturale legge da sinistra a destra.

Mettere <fileun inizio della pipeline è anche meno leggibile del gatto, direi. Una parola è più leggibile di un simbolo, specialmente un simbolo che sembra indicare la direzione sbagliata.

L'uso catconserva il command | command | commandformato.

Una cosa che le altre risposte qui non sembrano aver affrontato direttamente è che l'uso in catquesto modo non è "inutile", nel senso che "viene generato un processo di gatto estraneo che non funziona"; è inutile nel senso che "viene generato un processo cat che fa solo lavori non necessari".

Nel caso di questi due:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

la shell avvia un processo sed che legge da alcuni file o stdin (rispettivamente) e quindi esegue alcune elaborazioni - legge fino a quando non colpisce una nuova riga, sostituisce il primo "pippo" (se presente) su quella linea con "barra", quindi stampa quella linea a stdout e loop.

In caso di:

cat somefile | sed 's/foo/bar/'

La shell genera un processo cat e un processo sed e collega lo stdout del gatto allo stdin di sed. Il processo cat legge un file di diversi chilogrammi o forse mega byte dal file, quindi lo scrive nel suo stdout, dove il sed sommand raccoglie da lì come nel secondo esempio sopra. Mentre sed sta elaborando quel pezzo, il gatto sta leggendo un altro pezzo e lo sta scrivendo sul suo stdout per sed su cui lavorare.

In altre parole, il lavoro extra richiesto aggiungendo il catcomando non è solo il lavoro extra di generare un catprocesso extra , è anche il lavoro extra di leggere e scrivere i byte del file due volte anziché una volta. Ora, praticamente parlando e su sistemi moderni, ciò non fa una grande differenza: potrebbe far fare al tuo sistema alcuni microsecondi di lavoro inutile. Ma se è per uno script che prevedi di distribuire, potenzialmente alle persone che lo usano su macchine che sono già sottodimensionate, alcuni microsecondi possono sommarsi a molte iterazioni.