Devo me preocupar com gatos desnecessários?

Muitos utilitários de linha de comando podem receber suas entradas de um canal ou como um argumento de nome de arquivo. Para scripts shell longos, acho que iniciar a cadeia com a cattorna mais legível, principalmente se o primeiro comando precisar de argumentos de várias linhas.

Comparar

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

e

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

O último método é menos eficiente? Se sim, a diferença é suficiente para se preocupar se o script é executado, digamos, uma vez por segundo? A diferença de legibilidade não é enorme.

A resposta "definitiva" é obviamente trazida a você pelo The Useless Use of catAward .

O objetivo do gato é concatenar (ou "catenar") os arquivos. Se for apenas um arquivo, concatená-lo sem nada é uma perda de tempo e custa um processo.

A instanciação de um gato apenas para que seu código seja lido de maneira diferente gera apenas mais um processo e mais um conjunto de fluxos de entrada / saída que não são necessários. Normalmente, a retenção real em seus scripts será loops ineficientes e processamento real. Na maioria dos sistemas modernos, um extra catnão prejudica seu desempenho, mas quase sempre existe outra maneira de escrever seu código.

A maioria dos programas, como você observa, pode aceitar um argumento para o arquivo de entrada. No entanto, sempre há o shell interno <que pode ser usado onde quer que um fluxo STDIN seja esperado, o que poupa um processo, fazendo o trabalho no processo do shell que já está em execução.

Você pode até ser criativo com ONDE escrevê-lo. Normalmente, ele seria colocado no final de um comando antes de você especificar qualquer redirecionamento ou canal de saída como este:

sed s/blah/blaha/ < data | pipe

Mas não precisa ser assim. Pode até vir em primeiro lugar. Por exemplo, seu código de exemplo pode ser escrito assim:

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

Se a sua legibilidade é um problema e seu código é confuso o suficiente para que a adição de uma linha catseja esperada para facilitar o acompanhamento, existem outras maneiras de limpar seu código. Um que eu uso muito que ajuda a tornar os scripts fáceis de descobrir depois é dividir os pipes em conjuntos lógicos e salvá-los em funções. O código do script se torna muito natural e qualquer parte do pipline é mais fácil de depurar.

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

fix_blahs < data

Você pode então continuar com fix_blahs < data | fix_frogs | reorder | format_for_sql. Um pipleline com a seguinte leitura é realmente fácil de seguir e os componentes individuais podem ser depurados facilmente em suas respectivas funções.

Aqui está um resumo de algumas das desvantagens de:

cat $file | cmd

sobre

< $file cmd

• Primeiro, uma observação: faltam (intencionalmente para o objetivo da discussão) aspas duplas $fileacima. No caso de cat, isso é sempre um problema, exceto zsh; no caso do redirecionamento, isso é apenas um problema para bashou ksh88e, para alguns outros shells, apenas quando interativos (não em scripts).
• A desvantagem mais citada é o processo extra que está sendo gerado. Note que se cmdestá embutido, são 2 processos em alguns shells bash.
• Ainda na frente do desempenho, exceto nos shells onde catestá embutido, esse também é um comando extra sendo executado (e, é claro, carregado e inicializado (e as bibliotecas às quais está vinculado também)).
• Ainda em frente ao desempenho, para arquivos grandes, isso significa que o sistema terá de agendar o alternadamente cate cmdprocessos e constantemente encher e esvaziar o buffer pipe. Mesmo cmdque 1GBgrandes read()chamadas de sistema por vez, o controle precise ir e voltar entre cate cmdporque um canal não pode conter mais do que alguns kilobytes de dados por vez.
• Alguns cmds (como wc -c) podem fazer algumas otimizações quando o stdin é um arquivo regular, com o qual não conseguem fazer, cat | cmdjá que o stdin é apenas um cano. Com cate um pipe, isso também significa que eles não podem estar seek()no arquivo. Para comandos como tacou tail, isso faz uma enorme diferença no desempenho, pois significa que cateles precisam armazenar toda a entrada na memória.
• O cat $file, e até a versão mais correta cat -- "$file", não funcionarão corretamente para alguns nomes de arquivos específicos, como -( --helpou qualquer coisa que comece com -se você esquecer o --). Se alguém insistir em usar cat, provavelmente deve usar em cat < "$file" | cmdvez de confiabilidade.
• Se $filenão puder ser aberto para leitura (acesso negado, não existe ...), < "$file" cmdreportará uma mensagem de erro consistente (pelo shell) e não será executado cmd, enquanto cat $file | cmdainda será executado, cmdmas com seu stdin parecendo um arquivo vazio. Isso também significa que, em coisas como < file cmd > file2, file2não é derrotado se filenão puder ser aberto.

Colocar <fileno final de um pipeline é menos legível do que ter cat fileno início. O inglês natural lê da esquerda para a direita.

Colocar <fileo início do pipeline também é menos legível que o gato, eu diria. Uma palavra é mais legível que um símbolo, especialmente um símbolo que parece apontar o caminho errado.

O uso catpreserva o command | command | commandformato.

Uma coisa que as outras respostas aqui não parecem ter abordado diretamente é que usar catdessa forma não é "inútil" no sentido de que "um processo estranho de gato é gerado e não funciona"; é inútil no sentido de que "é gerado um processo de gato que faz apenas trabalho desnecessário".

No caso destes dois:

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

o shell inicia um processo sed que lê de algum arquivo ou stdin (respectivamente) e depois faz algum processamento - ele lê até atingir uma nova linha, substitui o primeiro 'foo' (se houver) nessa linha por 'bar' e depois imprime essa linha para stdout e loops.

No caso de:

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

A concha gera um processo de gato e um processo de sed e liga o stdout do gato ao stdin do sed. O processo do gato lê um pedaço de vários quilos ou talvez megabytes do arquivo e, em seguida, grava isso em seu stdout, onde o sommand começa a partir daí, como no segundo exemplo acima. Enquanto o sed está processando esse pedaço, o gato está lendo outro pedaço e escrevendo-o no stdout para que o sed trabalhe em seguida.

Em outras palavras, o trabalho extra necessário para adicionar o catcomando não é apenas o trabalho extra de gerar um catprocesso extra , é também o trabalho extra de ler e gravar os bytes do arquivo duas vezes em vez de uma vez. Agora, praticamente falando e em sistemas modernos, isso não faz muita diferença - pode fazer com que seu sistema faça alguns microssegundos de trabalho desnecessário. Mas se for para um script que você planeja distribuir, potencialmente para as pessoas que o usam em máquinas que já estão com pouca potência, alguns microssegundos podem adicionar várias iterações.