Probablemente se encuentre en muchas preguntas frecuentes, en lugar de usar:

cat file | command

(que se llama uso inútil de gato), la forma correcta se supone que es:

command < file

De la segunda forma, "correcta": el sistema operativo no tiene que generar un proceso adicional.
A pesar de saber eso, seguí usando gato inútil por 2 razones.

1. más estético: me gusta cuando los datos se mueven uniformemente solo de izquierda a derecha. Y es más fácil de reemplazar catcon otra cosa ( gzcat, echo, ...), añadir un segundo archivo o insertar el nuevo filtro ( pv, mbuffer, grep...).

2. "Sentí" que podría ser más rápido en algunos casos. Más rápido porque hay 2 procesos, el primero ( cat) hace la lectura y el segundo hace lo que sea. Y pueden ejecutarse en paralelo, lo que a veces significa una ejecución más rápida.

¿Es correcta mi lógica (por segunda razón)?

No estaba al tanto del premio hasta hoy, cuando un novato trató de acusarme del UUOC por una de mis respuestas. Fue un cat file.txt | grep foo | cut ... | cut .... Le di una parte de mi mente, y solo después de hacerlo visité el enlace que me dio refiriéndose a los orígenes del premio y la práctica de hacerlo. Una búsqueda más profunda me llevó a esta pregunta. Algo desafortunadamente, a pesar de una consideración consciente, ninguna de las respuestas incluía mi fundamento.

No había tenido la intención de estar a la defensiva al responderle. Después de todo, en mis años más jóvenes, habría escrito el comando grep foo file.txt | cut ... | cut ...porque cada vez que haces los sencillos frecuentes grep, aprendes la ubicación del argumento del archivo y ya sabes que el primero es el patrón y los últimos son los nombres de los archivos.

Fue una elección consciente de usar catcuando respondí a la pregunta, en parte por una razón de "buen gusto" (en palabras de Linus Torvalds) pero principalmente por una razón imperiosa de función.

La última razón es más importante, así que la publicaré primero. Cuando ofrezco una tubería como solución, espero que sea reutilizable. Es muy probable que una tubería se agregue al final o se empalme en otra tubería. En ese caso, tener un argumento de archivo para grep arruina la reutilización, y muy posiblemente hacerlo en silencio sin un mensaje de error si el argumento de archivo existe. I. e. grep foo xyz | grep bar xyz | wcle dará cuántas líneas xyzcontiene barmientras espera la cantidad de líneas que contienen tanto fooy bar. Tener que cambiar argumentos a un comando en una canalización antes de usarlo es propenso a errores. Si a eso le sumamos la posibilidad de fallos silenciosos, se convierte en una práctica particularmente insidiosa.

La primera razón tampoco carece de importancia, ya que mucho " buen gusto " es simplemente una razón subconsciente intuitiva para cosas como los fallos silenciosos anteriores en los que no se puede pensar justo en el momento en que una persona que necesita educación dice "pero no es ese gato inútil ".

Sin embargo, intentaré también hacer consciente la antigua razón de "buen gusto" que mencioné. Esa razón tiene que ver con el espíritu de diseño ortogonal de Unix. grepno lo hace cuty lsno lo hace grep. Por lo tanto, al menos grep foo file1 file2 file3va en contra del espíritu de diseño. La forma ortogonal de hacerlo es cat file1 file2 file3 | grep foo. Ahora, grep foo file1es simplemente un caso especial de grep foo file1 file2 file3, y si no lo trata de la misma manera, al menos está agotando los ciclos del reloj cerebral tratando de evitar el premio inútil del gato.

Eso nos lleva al argumento de que grep foo file1 file2 file3está concatenando, y catconcatena por lo que es apropiado cat file1 file2 file3pero porque catno está concatenando en, cat file1 | grep foopor lo tanto, estamos violando el espíritu tanto del catUnix como del todopoderoso. Bueno, si ese fuera el caso, Unix necesitaría un comando diferente para leer la salida de un archivo y escupirlo en stdout (no paginarlo ni nada más que un simple escupir en stdout). Entonces, tendría la situación en la que dice cat file1 file2o dice dog file1y recuerda concienzudamente evitar cat file1para evitar obtener el premio, al mismo tiempo que evita, dog file1 file2ya que con suerte el diseño dogarrojaría un error si se especifican varios archivos.

Con suerte, en este punto, simpatizará con los diseñadores de Unix por no incluir un comando separado para escupir un archivo en la salida estándar, al mismo tiempo que nombra catpara concatenar en lugar de darle otro nombre. <edit>eliminó los comentarios incorrectos <, de hecho, <es una función eficiente sin copia para escupir un archivo a la salida estándar que puede colocar al comienzo de una canalización para que los diseñadores de Unix incluyan algo específicamente para esto</edit>

La siguiente pregunta es ¿por qué es importante tener comandos que simplemente escupen un archivo o la concatenación de varios archivos a la salida estándar, sin ningún procesamiento adicional? Una razón es evitar tener cada comando de Unix que opera en una entrada estándar para saber cómo analizar al menos un argumento de archivo de línea de comando y usarlo como entrada si existe. La segunda razón es evitar que los usuarios tengan que recordar: (a) dónde van los argumentos del nombre de archivo; y (b) evitar el error silencioso de la tubería como se mencionó anteriormente.

Eso nos lleva al por qué greptiene la lógica adicional. La razón es permitir la fluidez del usuario para los comandos que se utilizan con frecuencia y de forma independiente (en lugar de como una canalización). Es un ligero compromiso de ortogonalidad para una ganancia significativa en usabilidad. No todos los comandos deben diseñarse de esta manera y los comandos que no se utilizan con frecuencia deben evitar por completo la lógica adicional de los argumentos del archivo (recuerde que la lógica adicional conduce a una fragilidad innecesaria (la posibilidad de un error)). La excepción es permitir argumentos de archivo como en el caso de grep. (Por cierto, tenga en cuenta que lstiene una razón completamente diferente para no solo aceptar, sino también requerir argumentos de archivo)

Finalmente, lo que podría haberse hecho mejor es si comandos excepcionales como grep(pero no necesariamente ls) generan un error si la entrada estándar también está disponible cuando se especifican los argumentos del archivo.

¡No!

En primer lugar, no importa en qué parte de un comando ocurra la redirección. Entonces, si le gusta su redirección a la izquierda de su comando, está bien:

< somefile command

es lo mismo que

command < somefile

En segundo lugar, hay n + 1 procesos y una subcapa cuando se usa una tubería. Es decididamente más lento. En algunos casos, n habría sido cero (por ejemplo, cuando está redirigiendo a un shell incorporado), por lo que al usarlo catestá agregando un nuevo proceso completamente innecesariamente.

Como generalización, siempre que te encuentres usando una tubería, vale la pena tomar 30 segundos para ver si puedes eliminarla. (Pero probablemente no valga la pena tomar más de 30 segundos). A continuación, se muestran algunos ejemplos en los que las tuberías y los procesos se utilizan con frecuencia innecesariamente:

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)

Siéntase libre de editar para agregar más ejemplos.

No estoy de acuerdo con la mayoría de los casos del Premio UUOC excesivamente presumido porque, cuando se enseña a otra persona, cates un marcador de posición conveniente para cualquier comando o canalización de comandos crujiente y complicada que produce resultados adecuados para el problema o la tarea que se está discutiendo.

Esto es especialmente cierto en sitios como Stack Overflow, ServerFault, Unix y Linux o cualquiera de los sitios SE.

Si alguien pregunta específicamente sobre la optimización, o si desea agregar información adicional al respecto, entonces, excelente, hable sobre cómo usar cat es ineficiente. ¡Pero no reprenda a las personas porque eligieron apuntar a la simplicidad y la facilidad de comprensión en sus ejemplos en lugar de mirarme-qué-genial-soy-! complejidad.

En resumen, porque el gato no siempre es gato.

También porque la mayoría de las personas que disfrutan de la concesión de UUOC lo hacen porque están más preocupados por presumir de lo "inteligentes" que son que por ayudar o enseñar a las personas. En realidad, demuestran que probablemente son solo otro novato que ha encontrado un palo pequeño para golpear a sus compañeros.

Actualizar

Aquí hay otro UUOC que publiqué en una respuesta en 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
}

Los pedantes de UUOC dirían que eso es un UUOC porque es fácilmente posible establecer $filterla cadena vacía por defecto y hacer que la ifdeclaración lo haga, filter='| grep -v "^$"'pero en mi opinión, al no incrustar el carácter de tubería en $filter, este "inútil" cattiene el propósito extremadamente útil de autodocumentar el hecho que $filteren la printflínea no es solo otro argumento sqlplus, es un filtro de salida opcional seleccionable por el usuario.

Si hay alguna necesidad de tener múltiples filtros de salida opcionales, el procesamiento de las opciones podría simplemente anexados | whatevera $filtertan a menudo como sea necesario - una adicional caten la tubería no se va a hacer daño a nada ni causa ninguna pérdida notable de rendimiento.

Con la versión UUoC, cattiene que leer el archivo en la memoria, luego escribirlo en la tubería, y el comando tiene que leer los datos de la tubería, por lo que el kernel tiene que copiar todo el archivo tres veces, mientras que en el caso redirigido, el kernel solo tiene que copiar el archivo una vez. Es más rápido hacer algo una vez que hacerlo tres veces.

Utilizando:

cat "$@" | command

es un uso completamente diferente y no necesariamente inútil de cat. Aún es inútil si el comando es un filtro estándar que acepta cero o más argumentos de nombre de archivo y los procesa a su vez. Considere el trcomando: es un filtro puro que ignora o rechaza los argumentos del nombre de archivo. Para alimentarlo con varios archivos, debe usar catcomo se muestra. (Por supuesto, hay una discusión separada de que el diseño de trno es muy bueno; no hay una razón real por la que no pudo haber sido diseñado como un filtro estándar). Esto también podría ser válido si desea que el comando trate todas las entradas como un un solo archivo en lugar de varios archivos separados, incluso si el comando acepta varios archivos separados: por ejemplo, wces un comando de este tipo.

Es el cat single-filecaso que es incondicionalmente inútil.

En defensa del gato:

Si,

   < input process > output 

o

   process < input > output 

es más eficiente, pero muchas invocaciones no tienen problemas de rendimiento, por lo que no le importa.

razones ergonómicas:

Estamos acostumbrados a leer de izquierda a derecha, por lo que un comando como

    cat infile | process1 | process2 > outfile

es trivial de entender.

    process1 < infile | process2 > outfile

tiene que saltar sobre el proceso1 y luego leer de izquierda a derecha. Esto se puede curar con:

    < infile process1 | process2 > outfile

parece de alguna manera, como si hubiera una flecha apuntando hacia la izquierda, donde no hay nada. Más confuso y que parece una cita elegante es:

    process1 > outfile < infile

y la generación de scripts suele ser un proceso iterativo,

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

donde ve su progreso paso a paso, mientras

    < file 

ni siquiera funciona. Las formas simples son menos propensas a errores y la catenación de comandos ergonómica es simple con cat.

Otro tema es que la mayoría de las personas estuvieron expuestas a> y <como operadores de comparación, mucho antes de usar una computadora y cuando usan una computadora como programadores, están mucho más expuestas a estos como tales.

Y comparar dos operandos con <y> es contra conmutativo, lo que significa

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

Recuerdo la primera vez que usé <para la redirección de entrada, temí

a.sh < file 

podría significar lo mismo que

file > a.sh

y de alguna manera sobrescribir mi script a.sh. Quizás este sea un problema para muchos principiantes.

diferencias raras

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

Este último se puede utilizar en los cálculos directamente.

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

Por supuesto, el <también se puede usar aquí, en lugar de un parámetro de archivo:

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

pero ¿a quién le importa - 15k?

Si de vez en cuando me encontrara con problemas, seguramente cambiaría mi hábito de invocar a cat.

Cuando se utilizan archivos muy grandes o muchos, muchos, está bien evitar el uso de gatos. Para la mayoría de las preguntas, el uso de cat es ortogonal, fuera de tema, no es un problema.

Comenzar con estos inútiles e inútiles debates sobre gatos sobre cada segundo tema de caparazón es solo molesto y aburrido. Consiga una vida y espere su minuto de fama, cuando se trata de cuestiones de rendimiento.

Un problema adicional es que la tubería puede enmascarar silenciosamente una subcapa. Para este ejemplo, lo reemplazaré catpor echo, pero existe el mismo problema.

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

echo "$x"

Puede esperar xcontener foo, pero no es así. El xque estableciste se generó en una subcapa para ejecutar el whilebucle. xen el shell que inició la canalización tiene un valor no relacionado o no está configurado en absoluto.

En bash4, puede configurar algunas opciones de shell para que el último comando de un pipeline se ejecute en el mismo shell que el que inicia el pipeline, pero luego puede intentar esto

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

y xes una vez más local para el whilesubshell de.

Como alguien que regularmente señala esto y otros antipatrones de programación de shell, me siento obligado, tardíamente, a intervenir.

El script de shell es en gran medida un lenguaje de copiar / pegar. Para la mayoría de las personas que escriben scripts de shell, no están en él para aprender el idioma; es solo un obstáculo que deben superar para poder seguir haciendo cosas en los idiomas con los que están familiarizados.

En ese contexto, lo veo como disruptivo y potencialmente incluso destructivo para propagar varios anti-patrones de secuencias de comandos de shell. El código que alguien encuentra en Stack Overflow idealmente debería ser posible copiar / pegar en su entorno con cambios mínimos y una comprensión incompleta.

Entre los muchos recursos de scripts de shell en la red, Stack Overflow es inusual ya que los usuarios pueden ayudar a dar forma a la calidad del sitio editando las preguntas y respuestas en el sitio. Sin embargo, las ediciones de código pueden ser problemáticas porque es fácil realizar cambios que no fueron previstos por el autor del código. Por lo tanto, tendemos a dejar comentarios para sugerir cambios en el código.

La UUCA y los comentarios de antipatrón relacionados no son solo para los autores del código que comentamos; son también una advertencia para ayudar a los lectores del sitio a darse cuenta de los problemas en el código que encuentran aquí.

No podemos esperar lograr una situación en la que ninguna respuesta en Stack Overflow recomiende cats inútiles (o variables sin comillas chmod 777, o una gran variedad de otras plagas antipatrón), pero al menos podemos ayudar a educar al usuario que está a punto de copiar / pegue este código en el bucle cerrado más interno de su script que se ejecuta millones de veces.

En cuanto a razones técnicas, la sabiduría tradicional es que debemos tratar de minimizar el número de procesos externos; esto sigue siendo una buena guía general al escribir scripts de shell.

A menudo lo uso cat file | myprogramen ejemplos. En algún momento me acusan de uso inútil del gato ( http://porkmail.org/era/unix/award.html ). No estoy de acuerdo por las siguientes razones:

• Es fácil comprender lo que está pasando.

  Cuando lee un comando de UNIX, espera un comando seguido de argumentos seguidos de una redirección. Es posible colocar la redirección en cualquier lugar, pero rara vez se ve, por lo que las personas tendrán más dificultades para leer el ejemplo. Yo creo

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

  es más fácil de leer que

  program1 -o option -b option < foo | program2

  Si mueve la redirección al principio, está confundiendo a las personas que no están acostumbradas a esta sintaxis:

  < foo program1 -o option -b option | program2

  y los ejemplos deben ser fáciles de entender.

• Es fácil de cambiar.

  Si sabe que el programa puede leer cat, normalmente puede asumir que puede leer la salida de cualquier programa que envíe a STDOUT y, por lo tanto, puede adaptarlo a sus propias necesidades y obtener resultados predecibles.

• Destaca que el programa no falla si STDIN no es un archivo.

  No es seguro asumir que si program1 < foofunciona cat foo | program1, también funcionará. Sin embargo, es seguro asumir lo contrario. Este programa funciona si STDIN es un archivo, pero falla si la entrada es una tubería, porque usa seek:

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

Costo de desempeño

Hay un costo por hacer el adicional cat. Para dar una idea de cuánto ejecuté algunas pruebas para simular la línea base ( cat), el rendimiento bajo ( bzip2), el rendimiento medio ( gzip) y el rendimiento alto ( 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

Las pruebas se ejecutaron en un sistema de gama baja (0,6 GHz) y una computadora portátil normal (2,2 GHz). Se ejecutaron 10 veces en cada sistema y se eligió el mejor momento para imitar la situación óptima para cada prueba. El $ ISO era ubuntu-11.04-desktop-i386.iso. (Tablas más bonitas aquí: 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

Los resultados muestran que para un rendimiento bajo y medio, el costo es del orden del 1%. Esto está dentro de la incertidumbre de las mediciones, por lo que en la práctica no hay diferencia.

Para un alto rendimiento, la diferencia es mayor y existe una clara diferencia entre los dos.

Eso lleva a la conclusión: debe usar en <lugar de cat |si:

• la complejidad del procesamiento es similar a un simple grep
• el rendimiento importa más que la legibilidad.

De lo contrario, no importa si usa <o cat |.

Y, por lo tanto, solo debe otorgar un premio UUoC si y solo si:

• puede medir una diferencia significativa en el rendimiento (publique sus mediciones cuando entregue el premio)
• el rendimiento importa más que la legibilidad.

Creo que (la forma tradicional) usar pipe es un poco más rápido; en mi caja usé el stracecomando para ver qué está pasando:

Sin tubería:

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)                           = ?

Y con pipa:

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

Puede hacer algunas pruebas con stracey timeordenar con más y más comandos para una buena evaluación comparativa.