Jest to prawdopodobnie w wielu często zadawanych pytaniach - zamiast używać:

cat file | command

(co nazywa się bezużytecznym użyciem kota), poprawny sposób powinien być:

command < file

W drugim, „poprawnym” sposobie - system operacyjny nie musi generować dodatkowego procesu.
Pomimo tego, z 2 powodów nadal używałem bezużytecznego kota.

1. bardziej estetyczny - lubię, gdy dane przesuwają się równomiernie tylko od lewej do prawej. I łatwiej wymienić catna coś innego ( gzcat, echo...), dodać 2nd plik lub wstawić nowy filtr ( pv, mbuffer, grep...).

2. „Czułem”, że w niektórych przypadkach może być szybciej. Szybciej, ponieważ są 2 procesy, pierwszy ( cat) odczytuje, a drugi cokolwiek. Mogą działać równolegle, co czasami oznacza szybszą realizację.

Czy moja logika jest poprawna (z drugiego powodu)?

O nagrodzie nie wiedziałem, aż do dzisiaj, kiedy jakiś nowicjusz próbował przypisać mi UUOC za jedną z moich odpowiedzi. To był cat file.txt | grep foo | cut ... | cut .... Dałem mu trochę do zrozumienia i dopiero po tym, gdy to zrobiłem, odwiedziłem link, który mi podał, odnosząc się do pochodzenia nagrody i praktyki. Dalsze poszukiwania doprowadziły mnie do tego pytania. Nieco niestety, pomimo świadomego namysłu, żadna z odpowiedzi nie zawierała mojego uzasadnienia.

Nie chciałem być defensywny, odpowiadając mu. W końcu w moich młodszych latach napisałbym komendę tak, grep foo file.txt | cut ... | cut ...ponieważ za każdym razem, gdy robisz częste single grep, uczysz się umiejscowienia argumentu plik i jest już wiadomo, że pierwszy to wzorzec, a następne to nazwy plików.

Był to świadomy wybór, catgdy odpowiadałem na to pytanie, częściowo z powodu „dobrego smaku” (według słów Linusa Torvaldsa), ale głównie z nieodpartego powodu funkcji.

Ten ostatni powód jest ważniejszy, więc wypowiem go jako pierwszy. Kiedy oferuję rurociąg jako rozwiązanie, oczekuję, że będzie można go ponownie wykorzystać. Jest całkiem prawdopodobne, że rurociąg zostałby dodany na końcu lub połączony z innym rurociągiem. W takim przypadku posiadanie argumentu plikowego w celu grepa psuje możliwość ponownego użycia i całkiem możliwe, że zrobi to po cichu bez komunikatu o błędzie, jeśli argument plik istnieje. I. e. grep foo xyz | grep bar xyz | wcpoda, ile wierszy xyzzawiera, barpodczas gdy spodziewasz się liczby wierszy zawierających oba fooi bar. Konieczność zmiany argumentów na polecenie w potoku przed jego użyciem jest podatna na błędy. Dodaj do tego możliwość cichych niepowodzeń, a stanie się to szczególnie podstępną praktyką.

Ten pierwszy powód również nie jest nieważny, ponieważ wiele „ dobrego smaku ” jest po prostu intuicyjnym, podświadomym uzasadnieniem takich rzeczy, jak ciche niepowodzenia powyżej, o których nie możesz pomyśleć w momencie, gdy jakaś osoba potrzebująca edukacji mówi: „ale tak nie jest ten kot bezużyteczny ”.

Postaram się jednak również uświadomić poprzedni powód „dobrego smaku”, o którym wspomniałem. Powód ten ma związek z ortogonalnym duchem projektowania Uniksa. grepnie robi cuti lsnie robi grep. Dlatego przynajmniej grep foo file1 file2 file3jest sprzeczne z duchem projektowania. Jest to ortogonalne cat file1 file2 file3 | grep foo. To grep foo file1tylko szczególny przypadek grep foo file1 file2 file3, a jeśli nie traktujesz go tak samo, przynajmniej zużywasz cykle zegara mózgowego, próbując uniknąć bezużytecznej nagrody dla kota.

To prowadzi nas do argumentu, który grep foo file1 file2 file3jest konkatenacją i catkonkatenacją, więc jest to właściwe, cat file1 file2 file3ale ponieważ catnie jest konkatenowane, cat file1 | grep foodlatego naruszamy ducha cati wszechmocnego Uniksa. Cóż, gdyby tak było, Unix potrzebowałby innego polecenia, aby odczytać wyjście z jednego pliku i wypluć go na standardowe wyjście (nie paginować go ani cokolwiek po prostu spluwać na standardowe wyjście). Miałbyś więc sytuację, w której mówisz cat file1 file2lub mówisz, dog file1i sumiennie pamiętaj, aby uniknąć cat file1otrzymania nagrody, jednocześnie unikając, dog file1 file2ponieważ mam nadzieję, że projekt dogspowoduje błąd, jeśli określono wiele plików.

Miejmy nadzieję, że w tym momencie sympatyzujesz z projektantami Uniksa za to, że nie dołączali oddzielnego polecenia wypluwania pliku na standardowe wyjście, jednocześnie nadając mu nazwę catdo konkatenacji, zamiast nadawać mu inną nazwę. <edit>usunięto niepoprawne komentarze <w rzeczywistości <jest skutecznym narzędziem bez kopiowania do wypluwania pliku na standardowe wyjście, które można umieścić na początku potoku, więc projektanci Uniksa dodali coś specjalnie do tego celu</edit>

Kolejne pytanie brzmi: dlaczego ważne jest, aby polecenia, które po prostu wypluwają plik lub konkatenację kilku plików na standardowe wyjście, bez dalszego przetwarzania? Jednym z powodów jest unikanie posiadania każdego pojedynczego polecenia Uniksa, które działa na standardowym wejściu, aby wiedzieć, jak przeanalizować co najmniej jeden argument pliku wiersza poleceń i użyć go jako wejścia, jeśli istnieje. Drugim powodem jest uniknięcie konieczności pamiętania przez użytkowników: (a) gdzie znajdują się argumenty nazwy pliku; i (b) unikaj cichego błędu rurociągu, jak wspomniano powyżej.

To prowadzi nas do tego, dlaczego grepma dodatkową logikę. Uzasadnieniem jest umożliwienie użytkownikowi płynnego posługiwania się poleceniami, które są używane często i samodzielnie (a nie jako potok). Jest to niewielki kompromis ortogonalności w celu znacznego zwiększenia użyteczności. Nie wszystkie polecenia powinny być zaprojektowane w ten sposób, a polecenia, które nie są często używane, powinny całkowicie unikać dodatkowej logiki argumentów plikowych (pamiętaj, że dodatkowa logika prowadzi do niepotrzebnej kruchości (możliwość błędu)). Wyjątkiem jest dopuszczenie argumentów plikowych, takich jak w przypadku grep. (Nawiasem mówiąc, zwróć uwagę, że lsma zupełnie inny powód, aby nie tylko akceptować, ale prawie wymagać plików argumentów)

Wreszcie, co można było zrobić lepiej, to gdyby takie wyjątkowe polecenia, jak grep(ale niekoniecznie ls), generowały błąd, jeśli standardowe wejście jest również dostępne, gdy podano argumenty pliku.

Nie!

Przede wszystkim nie ma znaczenia, gdzie w poleceniu następuje przekierowanie. Więc jeśli podoba Ci się przekierowanie na lewo od polecenia, to w porządku:

< somefile command

jest taki sam jak

command < somefile

Po drugie, gdy używasz potoku , występuje n + 1 procesów i podpowłoka. Jest zdecydowanie wolniejszy. W niektórych przypadkach n byłoby równe zero (na przykład, gdy przekierowujesz do wbudowanej powłoki), więc używając cat, dodajesz nowy proces całkowicie niepotrzebnie.

Ogólnie rzecz biorąc, za każdym razem, gdy używasz fajki, warto poświęcić 30 sekund na sprawdzenie, czy możesz ją wyeliminować. (Ale prawdopodobnie nie warto zajmować więcej niż 30 sekund.) Oto kilka przykładów, w których rury i procesy są często używane niepotrzebnie:

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)

Zapraszam do edycji, aby dodać więcej przykładów.

Nie zgadzam się z większością przypadków nadmiernie zadowolonej z siebie nagrody UUOC, ponieważ podczas nauczania kogoś innego catjest wygodnym miejscem na dowolne polecenie lub skomplikowany potok poleceń, które generują dane wyjściowe odpowiednie dla omawianego problemu lub zadania.

Jest to szczególnie prawdziwe w witrynach takich jak Stack Overflow, ServerFault, Unix i Linux lub w dowolnej witrynie SE.

Jeśli ktoś konkretnie pyta o optymalizację lub jeśli masz ochotę dodać dodatkowe informacje na jej temat, to świetnie, porozmawiaj o tym, że korzystanie z cat jest nieefektywne. Ale nie krytykuj ludzi, ponieważ zdecydowali się dążyć do prostoty i łatwości zrozumienia w swoich przykładach, zamiast patrzeć na mnie, jak fajnie-jestem! złożoność.

Krótko mówiąc, ponieważ kot nie zawsze jest kotem.

Również dlatego, że większość ludzi, którzy lubią nagradzać UUOC, robi to, ponieważ bardziej zależy im na tym, by pokazać, jak `` sprytni '' są, niż o pomaganie lub nauczanie ludzi. W rzeczywistości pokazują, że są prawdopodobnie kolejnym nowicjuszem, który znalazł mały kij do pokonania swoich rówieśników.

Aktualizacja

Oto kolejny UUOC, który zamieściłem w odpowiedzi na 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
}

Pedanci UUOC powiedzieliby, że to jest UUOC, ponieważ łatwo można ustawić $filterdomyślny pusty ciąg i mieć ifinstrukcję, filter='| grep -v "^$"'ale IMO, nie osadzając znaku potoku w $filter, to „bezużyteczne” catsłuży niezwykle użytecznemu celowi samodokumentowania faktu że $filterten printfwiersz nie jest tylko kolejnym argumentem sqlplus, jest to opcjonalny filtr wyjściowy wybierany przez użytkownika.

Jeśli nie ma żadnej potrzeby, aby mieć wiele opcjonalnych filtrów wyjściowych, przetwarzanie może po prostu opcja dołączania | whateverdo $filtertak często jak potrzeba - jeden dodatkowy catw rurociągu nie będzie bolało cokolwiek lub powoduje zauważalny spadek wydajności.

Z wersją UUoC, catmusi odczytać plik do pamięci, a następnie zapisać go do rury, a komenda musi odczytać dane z rury, więc jądro musi skopiować cały plik trzy razy, podczas gdy w przekierowanego wypadku jądro musi tylko raz skopiować plik. Szybciej jest zrobić coś raz, niż zrobić to trzy razy.

Za pomocą:

cat "$@" | command

jest zupełnie innym i niekoniecznie bezużytecznym zastosowaniem cat. Nadal jest bezużyteczne, jeśli polecenie jest standardowym filtrem, który akceptuje zero lub więcej argumentów nazw plików i przetwarza je po kolei. Rozważ trpolecenie: jest to czysty filtr, który ignoruje lub odrzuca argumenty nazwy pliku. Aby przesłać do niego wiele plików, musisz użyć, catjak pokazano. (Oczywiście istnieje osobna dyskusja, że ​​projekt trnie jest zbyt dobry; nie ma prawdziwego powodu, dla którego nie mógł zostać zaprojektowany jako standardowy filtr). Może to również być poprawne, jeśli chcesz, aby polecenie traktowało wszystkie dane wejściowe jako pojedynczy plik, a nie jako wiele oddzielnych plików, nawet jeśli polecenie zaakceptowałoby wiele oddzielnych plików: na przykład wcjest takim poleceniem.

Jest to cat single-fileprzypadek, który jest bezwarunkowo bezużyteczny.

W obronie kota:

Tak,

   < input process > output 

lub

   process < input > output 

jest bardziej wydajne, ale wiele wywołań nie ma problemów z wydajnością, więc nie przejmujesz się.

przyczyny ergonomiczne:

Jesteśmy przyzwyczajeni do czytania od lewej do prawej, więc polecenie takie jak

    cat infile | process1 | process2 > outfile

jest trywialne do zrozumienia.

    process1 < infile | process2 > outfile

musi przeskoczyć proces1, a następnie czytać od lewej do prawej. Można to wyleczyć:

    < infile process1 | process2 > outfile

wygląda jakoś, jakby była strzałka skierowana w lewo, gdzie nic nie ma. Bardziej zagmatwany i wyglądający jak fantazyjny cytat jest:

    process1 > outfile < infile

a generowanie skryptów jest często procesem iteracyjnym,

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

gdzie widzisz swój postęp krok po kroku, podczas gdy

    < file 

nawet nie działa. Proste sposoby są mniej podatne na błędy, a ergonomiczne wyszukiwanie poleceń jest proste dzięki cat.

Innym tematem jest to, że większość ludzi była narażona na działanie> i <jako operatorów porównania, na długo przed użyciem komputera i podczas korzystania z komputera jako programistów, są one znacznie częściej narażone na takie działanie.

Porównywanie dwóch operandów z <i> jest przeciwstawne, co oznacza

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

Obawiałem się, że pierwszy raz użyłem <do przekierowania danych wejściowych

a.sh < file 

może oznaczać to samo co

file > a.sh

i jakoś nadpisuję mój skrypt a.sh. Może jest to problem dla wielu początkujących.

rzadkie różnice

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

Ta ostatnia może być używana bezpośrednio w obliczeniach.

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

Oczywiście <może być tutaj również użyte zamiast parametru pliku:

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

ale kogo to obchodzi - 15k?

Gdybym od czasu do czasu napotkał jakieś problemy, z pewnością zmieniłbym swój nawyk wzywania kota.

Podczas używania bardzo dużych lub wielu, wielu plików unikanie cat jest w porządku. W większości pytań użycie kota jest ortogonalne, nie na temat, a nie problem.

Rozpoczynanie tych bezużytecznych dyskusji o kotach na co drugi temat powłoki jest tylko irytujące i nudne. Rób sobie życie i czekaj na swoją minutę sławy, odpowiadając na pytania dotyczące wydajności.

Dodatkowym problemem jest to, że rura może bezgłośnie maskować podpowłokę. W tym przykładzie, będę wymieniać catz echo, ale ten sam problem istnieje.

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

echo "$x"

Możesz spodziewać xsię, że zawiera foo, ale tak nie jest. xTy zestaw był w podpowłoce zrodził wykonać whilepętlę.xw powłoce, która uruchomiła potok, ma niepowiązaną wartość lub nie jest w ogóle ustawiona.

W bash4 możesz skonfigurować niektóre opcje powłoki, aby ostatnie polecenie potoku było wykonywane w tej samej powłoce, co ta, która uruchamia potok, ale możesz spróbować tego

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

i xjest ponownie lokalna dla whilepodpowłoki '.

Jako ktoś, kto regularnie zwraca uwagę na to i wiele innych antywzorów programowania powłoki, czuję się zobowiązany, z opóźnieniem, rozważyć.

Skrypt powłoki jest w dużej mierze językiem kopiuj / wklej. Dla większości ludzi, którzy piszą skrypty powłoki, nie uczą się języka; jest to po prostu przeszkoda, którą muszą pokonać, aby kontynuować pracę w języku (językach), które w rzeczywistości są nieco zaznajomione.

W tym kontekście uważam, że propagowanie różnych anty-wzorców skryptów powłoki jest destrukcyjne, a nawet destrukcyjne. Idealnie byłoby, gdyby kod, który ktoś znalazł w Stack Overflow, był możliwy do skopiowania / wklejenia do ich środowiska z minimalnymi zmianami i niepełnym zrozumieniem.

Wśród wielu zasobów skryptów powłoki w sieci, Stack Overflow jest niezwykłe, ponieważ użytkownicy mogą pomóc w kształtowaniu jakości witryny, edytując pytania i odpowiedzi w witrynie. Jednak edycje kodu mogą być problematyczne ponieważ łatwo jest wprowadzić zmiany, które nie były zamierzone przez autora kodu. Dlatego mamy tendencję do zostawiania komentarzy, aby zasugerować zmiany w kodzie.

UUCA i powiązane komentarze antywzorcowe są przeznaczone nie tylko dla autorów kodu, który komentujemy; są one tak samo emptor zastrzeżenie , aby pomóc czytelnikom w miejscu stać się świadomi problemów w kodzie one znaleźć tutaj.

Nie możemy mieć nadziei na osiągnięcie sytuacji, w której żadne odpowiedzi na Stack Overflow nie zalecają bezużytecznych cats (lub zmiennych niecytowanych lubchmod 777 wielu innych plag anty-wzorców), ale możemy przynajmniej pomóc w edukacji użytkownika, który ma zamiar skopiować / wklej ten kod do najbardziej wewnętrznej ścisłej pętli ich skryptu, który jest wykonywany miliony razy.

Jeśli chodzi o przyczyny techniczne, tradycyjna mądrość jest taka, że ​​powinniśmy starać się minimalizować liczbę procesów zewnętrznych; jest to nadal dobra ogólna wskazówka podczas pisania skryptów powłoki.

Często używam cat file | myprogramw przykładach. Czasami jestem oskarżany o bezużyteczne wykorzystanie kota ( http://porkmail.org/era/unix/award.html ). Nie zgadzam się z następujących powodów:

• Łatwo jest zrozumieć, co się dzieje.

  Czytając polecenie UNIX, oczekujesz polecenia, po którym następują argumenty, po których następuje przekierowanie. Możliwe jest umieszczenie przekierowania w dowolnym miejscu, ale jest to rzadko spotykane - w ten sposób ludzie będą mieli trudniej przeczytać przykład. wierzę

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

  jest łatwiejszy do odczytania niż

  program1 -o option -b option < foo | program2

  Jeśli przeniesiesz przekierowanie na początek, dezorientujesz ludzi, którzy nie są przyzwyczajeni do tej składni:

  < foo program1 -o option -b option | program2

  a przykłady powinny być łatwe do zrozumienia.

• Łatwo to zmienić.

  Jeśli wiesz, że program może czytać cat, możesz normalnie założyć, że może on odczytać dane wyjściowe z dowolnego programu, który wysyła do STDOUT, a zatem możesz dostosować go do własnych potrzeb i uzyskać przewidywalne wyniki.

• Podkreśla, że ​​program nie zawiedzie, jeśli STDIN nie jest plikiem.

  Nie jest bezpiecznie założyć, że jeśli program1 < fooprace następnie cat foo | program1będzie również pracować. Jednak można bezpiecznie założyć coś przeciwnego. Ten program działa, jeśli STDIN jest plikiem, ale kończy się niepowodzeniem, jeśli wejście jest potokiem, ponieważ używa funkcji seek:

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

Koszt wydajności

Dodatkowa opłata jest płatna cat. Aby dać wyobrażenie o tym, ile przeprowadziłem kilka testów, aby zasymulować linię bazową ( cat), niską przepustowość ( bzip2), średnią przepustowość ( gzip) i wysoką przepustowość ( 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

Testy zostały przeprowadzone na low-endowym systemie (0,6 GHz) i zwykłym laptopie (2,2 GHz). Przeprowadzono je 10 razy w każdym systemie i wybrano najlepszy czas, aby naśladować optymalną sytuację dla każdego testu. ISO ISO to ubuntu-11.04-desktop-i386.iso. (Ładniejsze tabele tutaj: 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

Wyniki pokazują, że przy małej i średniej przepustowości koszt jest rzędu 1%. Jest to dobrze mieszczące się w zakresie niepewności pomiarów, więc w praktyce nie ma różnicy.

W przypadku dużej przepustowości różnica jest większa i istnieje wyraźna różnica między nimi.

Prowadzi to do wniosku: <zamiast cat |if:

• złożoność przetwarzania jest podobna do prostego grepa
• wydajność jest ważniejsza niż czytelność.

W przeciwnym razie nie ma znaczenia, czy używasz, <czycat | .

Dlatego też powinieneś przyznać nagrodę UUoC tylko wtedy, gdy:

• możesz zmierzyć znaczącą różnicę w wydajności (opublikuj swoje pomiary, gdy przyznasz nagrodę)
• wydajność jest ważniejsza niż czytelność.

Myślę, że (w tradycyjny sposób) użycie potoku jest nieco szybsze; na moim pudełku użyłem stracepolecenia, aby zobaczyć, co się dzieje:

Bez rury:

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

I z rurą:

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

Możesz wykonać trochę testów stracei timepolecenia z coraz dłuższymi poleceniami, aby uzyskać dobre testy porównawcze.