Jak mogę stderr potoku, a nie stdout?

Mam program, który zapisuje informacje do stdouti stderr, i muszę przejść grepprzez to, co nadchodzi do stderr , ignorując standardowe wyjście .

Oczywiście mogę to zrobić w 2 krokach:

command > /dev/null 2> temp.file
grep 'something' temp.file

ale wolałbym móc to zrobić bez plików tymczasowych. Czy są jakieś sprytne sztuczki do pipingu?

Najpierw przekieruj stderr na stdout - potok; następnie przekieruj stdout na /dev/null(bez zmiany dokąd zmierza stderr):

command 2>&1 >/dev/null | grep 'something'

Szczegółowe informacje na temat przekierowania we / wy w całej jego różnorodności znajdują się w rozdziale Przekierowania w podręczniku użytkownika Bash.

Należy zauważyć, że sekwencja przekierowań we / wy jest interpretowana od lewej do prawej, ale potoki są konfigurowane przed interpretacją przekierowań we / wy. Deskryptory plików, takie jak 1 i 2, są odniesieniami do otwartych opisów plików. Operacja 2>&1powoduje, że deskryptor pliku 2 aka stderr odnosi się do tego samego otwartego opisu pliku, co deskryptor pliku 1 aka stdout, do którego obecnie się odnosi (patrz dup2()i open()). Operacja >/dev/nullnastępnie zmienia deskryptor pliku 1, tak aby odwoływał się do otwartego opisu pliku /dev/null, ale nie zmienia to faktu, że deskryptor pliku 2 odnosi się do otwartego opisu pliku, do którego pierwotnie wskazywał deskryptor pliku 1 - mianowicie potok.

Lub aby zamienić dane wyjściowe ze standardowego błędu i standardowego wyjścia, użyj:

command 3>&1 1>&2 2>&3

Spowoduje to utworzenie nowego deskryptora pliku (3) i przypisanie go do tego samego miejsca co 1 (standardowe wyjście), a następnie przypisanie fd 1 (standardowe wyjście) do tego samego miejsca co fd 2 (błąd standardowy) i na koniec przypisanie fd 2 (błąd standardowy ) w to samo miejsce, co fd 3 (wyjście standardowe).

Standardowy błąd jest teraz dostępny jako standardowe wyjście, a stare standardowe wyjście jest zachowywane jako standardowy błąd. Może to być przesada, ale mam nadzieję, że poda więcej szczegółów na temat deskryptorów plików Bash (dla każdego procesu dostępnych jest dziewięć).

W Bash możesz również przekierowywać do podpowłoki za pomocą podstawiania procesów :

command > >(stdlog pipe)  2> >(stderr pipe)

W rozpatrywanej sprawie:

command 2> >(grep 'something') >/dev/null

Łącząc najlepsze z tych odpowiedzi, jeśli:

command 2> >(grep -v something 1>&2)

... wtedy wszystkie stdout są zachowywane jako stdout i wszystkie stderr są zachowywane jako stderr, ale nie zobaczysz żadnych linii w stderr zawierających ciąg „coś”.

Ma to tę wyjątkową zaletę, że nie odwraca ani nie odrzuca stdout i stderr, nie łączy ich razem ani nie używa plików tymczasowych.

O wiele łatwiej jest wizualizować rzeczy, jeśli myślisz o tym, co naprawdę dzieje się z „przekierowaniami” i „potokami”. Przekierowania i potoki w bash robią jedną rzecz: modyfikują tam, gdzie wskazują deskryptory plików procesowych 0, 1 i 2 (patrz / proc / [pid] / fd / *).

Gdy rura lub „|” operator jest obecny w wierszu poleceń, pierwszą rzeczą, która się wydarzy, jest to, że bash tworzy FIFO i wskazuje FD 1 komendy po lewej stronie na FO 0 i wskazuje FD 0 komendy po prawej stronie na tę samą FIFO.

Następnie operatory przekierowania dla każdej strony są oceniane od lewej do prawej , a bieżące ustawienia są używane za każdym razem, gdy występuje duplikacja deskryptora. Jest to ważne, ponieważ odkąd rura została skonfigurowana jako pierwsza, FD1 (lewa strona) i FD0 (prawa strona) zostały już zmienione w stosunku do tego, czym normalnie mogły być, a ich powielanie odzwierciedla ten fakt.

Dlatego po wpisaniu czegoś takiego:

command 2>&1 >/dev/null | grep 'something'

Oto, co się dzieje, w kolejności:

1. tworzony jest potok (fifo). „polecenie FD1” jest wskazane na tej rurze. „grep FD0” również wskazuje na tę rurę
2. „polecenie FD2” jest wskazywane tam, gdzie „polecenie FD1” obecnie wskazuje (potok)
3. „polecenie FD1” wskazuje na / dev / null

Zatem wszystkie dane wyjściowe, które „polecenie” zapisuje na FD 2 (stderr), trafiają do potoku i są odczytywane przez „grep” po drugiej stronie. Wszystkie dane wyjściowe, które „komenda” zapisuje na FD 1 (stdout), trafiają do / dev / null.

Jeśli zamiast tego uruchom następujące polecenie:

command >/dev/null 2>&1 | grep 'something'

Oto co się dzieje:

1. tworzona jest rura i są do niej wskazywane „polecenie FD 1” i „grep FD 0”
2. „polecenie FD 1” wskazuje na / dev / null
3. „polecenie FD 2” wskazuje miejsce, w którym obecnie wskazuje FD 1 (/ dev / null)

Zatem wszystkie stdout i stderr z „polecenia” idą do / dev / null. Nic nie trafia do potoku, dlatego „grep” zostanie zamknięty bez wyświetlania czegokolwiek na ekranie.

Zauważ też, że przekierowania (deskryptory plików) mogą być tylko do odczytu (<), tylko do zapisu (>) lub do odczytu-zapisu (<>).

Ostatnia uwaga. To, czy program napisze coś do FD1 lub FD2, zależy wyłącznie od programisty. Dobra praktyka programowania nakazuje, aby komunikaty o błędach trafiały do ​​FD 2, a normalne wyjście do FD 1, ale często można znaleźć niechlujne programowanie, które łączy oba lub w inny sposób ignoruje konwencję.

Jeśli używasz Bash, użyj:

command >/dev/null |& grep "something"

http://www.gnu.org/software/bash/manual/bashref.html#Pipelines

Dla tych, którzy chcą przekierować stdout i stderr na stałe do plików, grep na stderr, ale zachowaj stdout do pisania wiadomości na tty:

# save tty-stdout to fd 3
exec 3>&1
# switch stdout and stderr, grep (-v) stderr for nasty messages and append to files
exec 2> >(grep -v "nasty_msg" >> std.err) >> std.out
# goes to the std.out
echo "my first message" >&1
# goes to the std.err
echo "a error message" >&2
# goes nowhere
echo "this nasty_msg won't appear anywhere" >&2
# goes to the tty
echo "a message on the terminal" >&3

Spowoduje to przekierowanie komendy 1 stderr do komendy 2 stdin, pozostawiając komendę 1 stdout bez zmian.

exec 3>&1
command1 2>&1 >&3 3>&- | command2 3>&-
exec 3>&-

Zaczerpnięte z LDP

Właśnie wymyśliłem rozwiązanie do wysyłania stdoutdo jednego polecenia i stderrdo drugiego, używając nazwanych potoków.

Tutaj idzie.

mkfifo stdout-target
mkfifo stderr-target
cat < stdout-target | command-for-stdout &
cat < stderr-target | command-for-stderr &
main-command 1>stdout-target 2>stderr-target

Prawdopodobnie dobrym pomysłem jest później usunięcie nazwanych rur.

Możesz użyć powłoki rc .

Najpierw zainstaluj pakiet (jest mniej niż 1 MB).

To przykład, w jaki sposób należy odrzucić standardowe wyjście i standardowy błąd potoku, aby grep w rc:

find /proc/ >[1] /dev/null |[2] grep task

Możesz to zrobić bez wychodzenia z Bash:

rc -c 'find /proc/ >[1] /dev/null |[2] grep task'

Jak zapewne zauważyłeś, możesz określić, który deskryptor pliku ma być przesyłany potokowo, za pomocą nawiasów po potoku.

Standardowe deskryptory plików są ponumerowane jako takie:

• 0: Standardowe wejście
• 1: Wyjście standardowe
• 2: Błąd standardowy

Staram się śledzić, ale to też działa,

command > /dev/null 2>&1 | grep 'something'