Isso provavelmente está em muitas perguntas frequentes - em vez de usar:

cat file | command

(que é chamado de uso inútil de gato), a maneira correta deve ser:

command < file

Na segunda maneira, "correta" - o SO não precisa gerar um processo extra.
Apesar de saber disso, continuei a usar gato inútil por 2 motivos.

1. mais estético - gosto quando os dados se movem uniformemente apenas da esquerda para a direita. E é mais fácil de substituir catcom algo mais ( gzcat, echo...), adicionar um segundo arquivo ou inserir novo filtro ( pv, mbuffer, grep...).

2. Eu "senti" que poderia ser mais rápido em alguns casos. Mais rápido porque há 2 processos, o primeiro ( cat) faz a leitura e o segundo faz tudo. E eles podem ser executados em paralelo, o que às vezes significa uma execução mais rápida.

Minha lógica está correta (pelo segundo motivo)?

Eu não sabia do prêmio até hoje, quando um novato tentou apontar o UUOC para mim por uma das minhas respostas. Era umcat file.txt | grep foo | cut ... | cut ... . Eu dei a ele um pedaço do que eu pensava, e só depois de fazer isso visitei o link que ele me deu referindo-se à origem do prêmio e à prática de fazê-lo. Pesquisas adicionais me levaram a esta pergunta Infelizmente, apesar da consideração consciente, nenhuma das respostas incluiu meu raciocínio.

Eu não queria ficar na defensiva ao responder a ele. Afinal, na minha juventude, eu teria escrito o comando grep foo file.txt | cut ... | cut ...porque sempre que você faz os simples greps frequentes, você aprende a localização do argumento do arquivo e já sabe que o primeiro é o padrão e os últimos são os nomes dos arquivos.

Foi uma escolha consciente a ser usada catquando respondi à pergunta, em parte por uma razão de "bom gosto" (nas palavras de Linus Torvalds), mas principalmente por uma razão convincente de função.

O último motivo é mais importante, então irei divulgá-lo primeiro. Quando eu ofereço um pipeline como solução, espero que ele seja reutilizável. É bastante provável que um pipeline seja adicionado no final ou unido em outro pipeline. Nesse caso, ter um argumento de arquivo para grep atrapalha a capacidade de reutilização, e muito possivelmente fazê-lo silenciosamente sem uma mensagem de erro se o argumento de arquivo existir. I. e. grep foo xyz | grep bar xyz | wclhe dará quantas linhas em xyzcontêm barenquanto você espera o número de linhas que contêm fooe bar. Ter que alterar os argumentos de um comando em um pipeline antes de usá-lo está sujeito a erros. Acrescente a isso a possibilidade de falhas silenciosas e torna-se uma prática particularmente insidiosa.

A primeira razão também não é sem importância, uma vez que muito " bom gosto " é meramente uma razão subconsciente intuitiva para coisas como as falhas silenciosas acima, nas quais você não consegue pensar direito no momento em que alguma pessoa que precisa de educação diz "mas não é aquele gato inútil ".

No entanto, tentarei também tornar consciente o antigo motivo do "bom gosto" que mencionei. Essa razão tem a ver com o espírito de design ortogonal do Unix. grepnão faz cute lsnão faz grep. Portanto, no mínimo grep foo file1 file2 file3vai contra o espírito do design. A maneira ortogonal de fazer isso é cat file1 file2 file3 | grep foo. Agora, grep foo file1é apenas um caso especial de grep foo file1 file2 file3, e se você não tratá-lo da mesma forma, você está pelo menos usando os ciclos do relógio cerebral tentando evitar o prêmio do gato inútil.

Isso nos leva ao argumento de que grep foo file1 file2 file3está concatenando, e catconcatena de forma apropriada, cat file1 file2 file3mas porque catnão está concatenando, cat file1 | grep fooportanto, estamos violando o espírito do cate do todo-poderoso Unix. Bem, se fosse esse o caso, então o Unix precisaria de um comando diferente para ler a saída de um arquivo e despejá-lo em stdout (não paginá-lo ou qualquer coisa apenas um spit puro em stdout). Portanto, você teria a situação em que diz cat file1 file2ou diz dog file1e conscienciosamente lembre-se de evitar cat file1para evitar o recebimento do prêmio, ao mesmo tempo que evita, dog file1 file2uma vez que, esperançosamente, o design de doggeraria um erro se vários arquivos fossem especificados.

Esperançosamente, neste ponto, você simpatiza com os designers do Unix por não incluir um comando separado para cuspir um arquivo para stdout, enquanto também nomeia catpara concatenar em vez de dar a ele algum outro nome. <edit>removeu comentários incorretos sobre <, de fato, <é um recurso eficiente de não copiar para cuspir um arquivo em stdout que você pode posicionar no início de um pipeline, então os designers do Unix incluíram algo especificamente para isso</edit>

A próxima pergunta é: por que é importante ter comandos que apenas geram um arquivo ou a concatenação de vários arquivos para o stdout, sem nenhum processamento posterior? Uma razão é evitar que cada comando Unix que opera na entrada padrão saiba como analisar pelo menos um argumento do arquivo de linha de comando e usá-lo como entrada, se existir. A segunda razão é evitar que os usuários tenham que se lembrar: (a) para onde vão os argumentos do nome do arquivo; e (b) evitar o bug do pipeline silencioso, conforme mencionado acima.

Isso nos leva ao porquê de grepter uma lógica extra. A lógica é permitir a fluência do usuário para comandos que são usados ​​com frequência e de forma autônoma (em vez de um pipeline). É um pequeno compromisso de ortogonalidade para um ganho significativo em usabilidade. Nem todos os comandos devem ser projetados dessa forma e os comandos que não são usados ​​com frequência devem evitar completamente a lógica extra de argumentos de arquivo (lembre-se de que a lógica extra leva a uma fragilidade desnecessária (a possibilidade de um bug)). A exceção é permitir argumentos de arquivo como no caso de grep. (A propósito, observe que lshá uma razão completamente diferente para não apenas aceitar, mas também exigir argumentos de arquivo)

Finalmente, o que poderia ter sido feito melhor seria se comandos excepcionais como grep(mas não necessariamente ls) gerassem um erro se a entrada padrão também estivesse disponível quando os argumentos do arquivo fossem especificados.

Não!

Em primeiro lugar, não importa onde em um comando o redirecionamento acontece. Portanto, se você gosta do redirecionamento para a esquerda do comando, tudo bem:

< somefile command

é o mesmo que

command < somefile

Em segundo lugar, existem n + 1 processos e um subshell acontecendo quando você usa um pipe. É decididamente mais lento. Em alguns casos, n seria zero (por exemplo, quando você está redirecionando para um shell embutido), então, ao usar, catvocê está adicionando um novo processo totalmente desnecessário.

Como generalização, sempre que você estiver usando um cano, vale a pena gastar 30 segundos para ver se você consegue eliminá-lo. (Mas provavelmente não vale a pena demorar muito mais do que 30 segundos.) Aqui estão alguns exemplos em que tubos e processos são usados ​​com frequência desnecessariamente:

for word in $(cat somefile); … # for word in $(<somefile); … (or better yet, while read < somefile)

grep something | awk stuff; # awk '/something/ stuff' (similar for sed)

echo something | command; # command <<< something (although echo would be necessary for pure POSIX)

Sinta-se à vontade para editar e adicionar mais exemplos.

Eu discordo da maioria dos casos do prêmio UUOC excessivamente presunçoso porque, ao ensinar outra pessoa, caté um marcador conveniente para qualquer comando ou pipeline complicado de comandos que produza saída adequada para o problema ou tarefa em discussão.

Isso é especialmente verdadeiro em sites como Stack Overflow, ServerFault, Unix e Linux ou qualquer um dos sites SE.

Se alguém perguntar especificamente sobre otimização, ou se você quiser adicionar informações extras sobre isso, ótimo, fale sobre como usar cat é ineficiente. Mas não repreenda as pessoas porque elas escolheram buscar simplicidade e facilidade de compreensão em seus exemplos, em vez de olhar para mim como sou legal! complexidade.

Resumindo, porque o gato nem sempre é gato.

Também porque a maioria das pessoas que gosta de premiar UUOCs o faz porque estão mais preocupadas em se exibir sobre o quão 'inteligentes' são do que em ajudar ou ensinar as pessoas. Na realidade, eles demonstram que provavelmente são apenas mais um novato que encontrou um pequeno graveto para bater em seus colegas.

Atualizar

Aqui está outro UUOC que postei em uma resposta em https://unix.stackexchange.com/a/301194/7696 :

sqlq() {
  local filter
  filter='cat'

  # very primitive, use getopts for real option handling.
  if [ "$1" == "--delete-blank-lines" ] ; then
    filter='grep -v "^$"'
    shift
  fi

  # each arg is piped into sqlplus as a separate command
  printf "%s\n" "$@" | sqlplus -S sss/eee@sid | $filter
}

Pedantes UUOC diriam que é um UUOC porque é facilmente possível tornar $filterpadrão para a string vazia e fazer com que a ifinstrução o faça, filter='| grep -v "^$"'mas IMO, por não incorporar o caractere de barra vertical $filter, este "inútil" catserve ao propósito extremamente útil de autodocumentar o fato que $filterna printflinha não é apenas outro argumento para sqlplus, é um filtro de saída opcional selecionável pelo usuário.

Se houver necessidade de vários filtros de saída opcionais, o processamento de opções pode apenas anexar com | whatevera $filterfrequência necessária - um extra catno pipeline não vai prejudicar nada ou causar qualquer perda perceptível de desempenho.

Com a versão UUoC, catdeve ler o arquivo na memória, depois gravá-lo no pipe, e o comando deve ler os dados do pipe, então o kernel tem que copiar o arquivo inteiro três vezes, enquanto no caso redirecionado, o kernel só precisa copiar o arquivo uma vez. É mais rápido fazer algo uma vez do que três vezes.

Usando:

cat "$@" | command

é um uso totalmente diferente e não necessariamente inútil de cat. Ainda é inútil se o comando for um filtro padrão que aceita zero ou mais argumentos de nome de arquivo e os processa sucessivamente. Considere o trcomando: é um filtro puro que ignora ou rejeita argumentos de nome de arquivo. Para alimentar vários arquivos nele, você deve usar catcomo mostrado. (Claro, há uma discussão separada de que o design do trnão é muito bom; não há nenhuma razão real para ele não ter sido projetado como um filtro padrão.) Isso também pode ser válido se você quiser que o comando trate todas as entradas como um arquivo único em vez de vários arquivos separados, mesmo se o comando aceitar vários arquivos separados: por exemplo, wcé esse comando.

É o cat single-filecaso que é incondicionalmente inútil.

Em defesa do gato:

Sim,

   < input process > output 

ou

   process < input > output 

é mais eficiente, mas muitas invocações não têm problemas de desempenho, então você não se importa.

razões ergonômicas:

Estamos acostumados a ler da esquerda para a direita, então um comando como

    cat infile | process1 | process2 > outfile

é trivial de entender.

    process1 < infile | process2 > outfile

tem que pular o processo 1 e depois ler da esquerda para a direita. Isso pode ser curado por:

    < infile process1 | process2 > outfile

parece de alguma forma, como se houvesse uma seta apontando para a esquerda, onde nada está. Mais confuso e parecendo uma citação sofisticada:

    process1 > outfile < infile

e gerar scripts geralmente é um processo iterativo,

    cat file 
    cat file | process1
    cat file | process1 | process2 
    cat file | process1 | process2 > outfile

onde você vê seu progresso passo a passo, enquanto

    < file 

nem mesmo funciona. As formas simples são menos propensas a erros e a catenação ergonômica do comando é simples com o gato.

Outro tópico é que a maioria das pessoas foi exposta a> e <como operadores de comparação, muito antes de usar um computador e ao usar um computador como programadores, é muito mais frequentemente exposta a estes como tal.

E comparar dois operandos com <e> é contra comutativo, o que significa

(a > b) == (b < a)

Lembro-me da primeira vez que usei <para redirecionamento de entrada, temi

a.sh < file 

pode significar o mesmo que

file > a.sh

e de alguma forma sobrescrever meu script a.sh. Talvez este seja um problema para muitos iniciantes.

diferenças raras

wc -c journal.txt
15666 journal.txt
cat journal.txt | wc -c 
15666

Este último pode ser usado em cálculos diretamente.

factor $(cat journal.txt | wc -c)

Claro que o <também pode ser usado aqui, em vez de um parâmetro de arquivo:

< journal.txt wc -c 
15666
wc -c < journal.txt
15666
    

mas quem se importa - 15k?

Se eu ocasionalmente tivesse problemas, certamente mudaria meu hábito de invocar gatos.

Ao usar arquivos muito grandes ou muitos, muitos, evitar gato é bom. Para a maioria das perguntas, o uso de gato é ortogonal, fora do tópico, não é um problema.

Começar esse uso inútil de discussão sobre gatos em cada segundo tópico de shell é apenas chato e chato. Pegue uma vida e espere pelo seu minuto de fama, ao lidar com questões de desempenho.

Um problema adicional é que o tubo pode mascarar silenciosamente uma subcamada. Para este exemplo, substituirei catpor echo, mas existe o mesmo problema.

echo "foo" | while read line; do
    x=$line
done

echo "$x"

Você pode esperar xconter foo, mas não o faz. O que xvocê definiu estava em um subshell gerado para executar o whileloop. xno shell que iniciou o pipeline tem um valor não relacionado ou não está definido.

No bash4, você pode configurar algumas opções de shell para que o último comando de um pipeline seja executado no mesmo shell daquele que inicia o pipeline, mas então você pode tentar isso

echo "foo" | while read line; do
    x=$line
done | awk '...'

e xé mais uma vez local para o whilesubshell de.

Como alguém que regularmente aponta isso e uma série de outros antipadrões de programação de shell, me sinto obrigado, tardiamente, a ponderar.

Shell script é basicamente uma linguagem de copiar / colar. Para a maioria das pessoas que escrevem scripts de shell, elas não querem aprender a linguagem; é apenas um obstáculo que eles precisam superar para continuar a fazer as coisas no (s) idioma (s) com os quais estão realmente familiarizados.

Nesse contexto, vejo como perturbador e potencialmente até destrutivo propagar vários anti-padrões de script de shell. O código que alguém encontra no Stack Overflow deve ser idealmente possível para copiar / colar em seu ambiente com alterações mínimas e compreensão incompleta.

Entre os muitos recursos de script de shell na rede, Stack Overflow é incomum porque os usuários podem ajudar a moldar a qualidade do site editando as perguntas e respostas no site. No entanto, as edições de código podem ser problemáticas porque é fácil fazer alterações que não foram pretendidas pelo autor do código. Portanto, tendemos a deixar comentários para sugerir alterações no código.

O UUCA e comentários antipadrões relacionados não são apenas para os autores do código que comentamos; eles são um caveat emptor para ajudar os leitores do site a se conscientizarem dos problemas no código que encontram aqui.

Não podemos esperar alcançar uma situação em que nenhuma resposta no Stack Overflow recomende cats inúteis (ou variáveis ​​não citadas, ou chmod 777, ou uma grande variedade de outras pragas antipadrão), mas podemos pelo menos ajudar a educar o usuário que está prestes a copiar / cole esse código no loop mais interno de seu script, que é executado milhões de vezes.

No que diz respeito às razões técnicas, a sabedoria tradicional é que devemos tentar minimizar o número de processos externos; isso continua sendo uma boa orientação geral ao escrever scripts de shell.

Costumo usar cat file | myprogramem exemplos. Às vezes estou sendo acusado de uso inútil de gato ( http://porkmail.org/era/unix/award.html ). Eu discordo pelos seguintes motivos:

• É fácil entender o que está acontecendo.

  Ao ler um comando UNIX, você espera um comando seguido de argumentos seguidos de redirecionamento. É possível colocar o redirecionamento em qualquer lugar, mas raramente é visto - portanto, as pessoas terão mais dificuldade em ler o exemplo. Acredito

  cat foo | program1 -o option -b option | program2

  é mais fácil de ler do que

  program1 -o option -b option < foo | program2

  Se você mover o redirecionamento para o início, estará confundindo as pessoas que não estão acostumadas com esta sintaxe:

  < foo program1 -o option -b option | program2

  e os exemplos devem ser fáceis de entender.

• É fácil mudar.

  Se você sabe que o programa pode ler cat, normalmente pode assumir que ele pode ler a saída de qualquer programa com saída para STDOUT e, portanto, pode adaptá-lo às suas próprias necessidades e obter resultados previsíveis.

• Salienta que o programa não falha, se STDIN não for um arquivo.

  Não é seguro presumir que, se program1 < foofuncionar, cat foo | program1também funcionará. No entanto, é seguro assumir o oposto. Este programa funciona se STDIN for um arquivo, mas falha se a entrada for um canal, porque usa a busca:

  # works
  < foo perl -e 'seek(STDIN,1,1) || die;print <STDIN>'
  
  # fails
  cat foo | perl -e 'seek(STDIN,1,1) || die;print <STDIN>'

Custo de desempenho

Há um custo para fazer o adicional cat. Para dar uma ideia de quanto eu executei alguns testes para simular a linha de base ( cat), baixa taxa de transferência ( bzip2), média ( gzip) e alta taxa de transferência ( grep).

cat $ISO | cat
< $ISO cat
cat $ISO | bzip2
< $ISO | bzip2
cat $ISO | gzip
< $ISO gzip
cat $ISO | grep no_such_string
< $ISO grep no_such_string

Os testes foram executados em um sistema low end (0,6 GHz) e um laptop comum (2,2 GHz). Eles foram executados 10 vezes em cada sistema e o melhor tempo foi escolhido para simular a situação ideal para cada teste. O $ ISO era ubuntu-11.04-desktop-i386.iso. (Tabelas mais bonitas aqui: http://oletange.blogspot.com/2013/10/useless-use-of-cat.html )

CPU                       0.6 GHz ARM
Command                   cat $ISO|                        <$ISO                            Diff                             Diff (pct)
Throughput \ Time (ms)    User       Sys        Real       User       Sys        Real       User       Sys        Real       User       Sys        Real
Baseline (cat)                     55      14453      33090         23       6937      33126         32       7516        -36        239        208         99
Low (bzip2)                   1945148      16094    1973754    1941727       5664    1959982       3420      10430      13772        100        284        100
Medium (gzip)                  413914      13383     431812     407016       5477     416760       6898       7906      15052        101        244        103
High (grep no_such_string)      80656      15133      99049      79180       4336      86885       1476      10797      12164        101        349        114

CPU                       Core i7 2.2 GHz
Command                   cat $ISO|           <$ISO             Diff          Diff (pct)
Throughput \ Time (ms)    User     Sys Real   User   Sys Real   User Sys Real User       Sys Real
Baseline (cat)                    0 356    215      1  84     88    0 272  127          0 423  244
Low (bzip2)                  136184 896 136765 136728 160 137131 -545 736 -366         99 560   99
Medium (gzip)                 26564 788  26791  26332 108  26492  232 680  298        100 729  101
High (grep no_such_string)      264 392    483    216  84    304   48 308  179        122 466  158

Os resultados mostram que para baixa e média vazão o custo é da ordem de 1%. Isso está dentro da incerteza das medições, portanto, na prática, não há diferença.

Para alto rendimento, a diferença é maior e há uma diferença clara entre os dois.

Isso leva à conclusão: você deve usar em <vez de cat |se:

• a complexidade do processamento é semelhante a um grep simples
• o desempenho é mais importante do que a legibilidade.

Caso contrário, não importa se você usa <oucat | .

E, portanto, você só deve dar um prêmio UUoC se e somente se:

• você pode medir uma diferença significativa no desempenho (publique suas medições quando der o prêmio)
• o desempenho é mais importante do que a legibilidade.

Acho que (da forma tradicional) usar cachimbo é um pouco mais rápido; na minha caixa eu useistrace comando para ver o que está acontecendo:

Sem tubo:

toc@UnixServer:~$ strace wc -l < wrong_output.c
execve("/usr/bin/wc", ["wc", "-l"], [/* 18 vars */]) = 0
brk(0)                                  = 0x8b50000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ad000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29107, ...}) = 0
mmap2(NULL, 29107, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77a5000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\222\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1552584, ...}) = 0
mmap2(NULL, 1563160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7627000
mmap2(0xb779f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178) = 0xb779f000
mmap2(0xb77a2000, 10776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77a2000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7626000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb76268d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb779f000, 8192, PROT_READ)   = 0
mprotect(0x804f000, 4096, PROT_READ)    = 0
mprotect(0xb77ce000, 4096, PROT_READ)   = 0
munmap(0xb77a5000, 29107)               = 0
brk(0)                                  = 0x8b50000
brk(0x8b71000)                          = 0x8b71000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5540198, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7426000
mmap2(NULL, 1507328, PROT_READ, MAP_PRIVATE, 3, 0x2a8) = 0xb72b6000
close(3)                                = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ac000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb77ac000, 4096)                = 0
open("/usr/share/locale/fr_FR.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr_FR.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr_FR/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/fr/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr_FR/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/fr/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=316721, ...}) = 0
mmap2(NULL, 316721, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7268000
close(3)                                = 0
open("/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=26064, ...}) = 0
mmap2(NULL, 26064, PROT_READ, MAP_SHARED, 3, 0) = 0xb7261000
close(3)                                = 0
read(0, "#include<stdio.h>\n\nint main(int "..., 16384) = 180
read(0, "", 16384)                      = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7260000
write(1, "13\n", 313
)                     = 3
close(0)                                = 0
close(1)                                = 0
munmap(0xb7260000, 4096)                = 0
close(2)                                = 0
exit_group(0)                           = ?

E com cachimbo:

toc@UnixServer:~$ strace cat wrong_output.c | wc -l
execve("/bin/cat", ["cat", "wrong_output.c"], [/* 18 vars */]) = 0
brk(0)                                  = 0xa017000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb774b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=29107, ...}) = 0
mmap2(NULL, 29107, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7743000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\222\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1552584, ...}) = 0
mmap2(NULL, 1563160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75c5000
mmap2(0xb773d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x178) = 0xb773d000
mmap2(0xb7740000, 10776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7740000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75c4000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb75c48d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb773d000, 8192, PROT_READ)   = 0
mprotect(0x8051000, 4096, PROT_READ)    = 0
mprotect(0xb776c000, 4096, PROT_READ)   = 0
munmap(0xb7743000, 29107)               = 0
brk(0)                                  = 0xa017000
brk(0xa038000)                          = 0xa038000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5540198, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb73c4000
mmap2(NULL, 1507328, PROT_READ, MAP_PRIVATE, 3, 0x2a8) = 0xb7254000
close(3)                                = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
open("wrong_output.c", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=180, ...}) = 0
read(3, "#include<stdio.h>\n\nint main(int "..., 32768) = 180
write(1, "#include<stdio.h>\n\nint main(int "..., 180) = 180
read(3, "", 32768)                      = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
13

Você pode fazer alguns testes stracee timecomandos com mais e mais comandos para um bom benchmarking.