Dlaczego przekierowywanie STDERR do / dev / null odbywa się w ten sposób?

To nie ma dla mnie sensu.

wibble > /dev/null 2>&1

Myślę, że miałoby to większy sens, gdyby było coś takiego:

wibble 2>&1 > /dev/null

Innymi słowy

Commands Output Sendall STDERRORS to STDOUT then SEND it all to /dev/null

Jaka jest kolejność przekierowywania poleceń xxx > /dev/null 2>1?

io-redirection

— kim jestem
źródło

Może ci się to przydać.

— rozcietrzewiacz

Dzięki @rozcietzewiacz, który właściwie dokładnie wyjaśnia moje pytanie

— whoami

Na środku tej strony na Wiki Grega znajduje się świetny fragment : „Jeśli nadal jesteś zdezorientowany, to prawdopodobnie dlatego, że zacząłeś od błędnego przekonania o tym, jak działają FD, i nie mogłeś porzucić tego nieporozumienia jeszcze. Nie martw się - to bardzo powszechne nieporozumienie i nie jesteś sam. … Wiele osób uważa, że w 2>&1jakiś sposób „łączy” lub „łączy” lub „łączy” dwie FD, tak że każda [kolejna] zmiana jednej z nich staje się zmianą drugiej. Nie o to chodzi."

— G-Man mówi„ Przywróć Monikę ”

Przekierowania są przetwarzane od lewej do prawej. Jeśli zrobisz

2>&1 1> /dev/null

Pierwsze przekierowanie stderrwskazuje na strumień, który stdoutwskazuje w tym czasie (który jest zasadniczo twoim tty). Nie tworzy stderraliasu stdout.

Następnie stdoutzostaje przekierowany do segmentu bitów. stdoutPrzekierowanie nie wpływa poprzednią stderrprzekierowanie. stderrnadal odnosi się do twojego tty.

Więc:

ls file_that_doesnt_exist 2>&1 1> /dev/null

wydrukuje tylko komunikat o błędzie na twoim terminalu.

Strona bashdokumentacji przekierowań wyraźnie wspomina o tym:

Pamiętaj, że kolejność przekierowań jest znacząca. Na przykład polecenie

          ls > dirlist 2>&1

kieruje zarówno standardowe wyjście, jak i błąd standardowy do dirlist pliku, podczas gdy polecenie

          ls 2>&1 > dirlist

kieruje tylko standardowe wyjście do pliku dirlist, ponieważ błąd standardowy został zduplikowany ze standardowego wyjścia, zanim standardowe wyjście zostało przekierowane do dirlist .

— Mata
źródło

Yay rozwiązuje moją zagadkę. Nadal uważam, że jest to mylące. ale znalazłem inną część na tej samej stronie, która jest interesująca pod względem &>/dev/nullsemantycznym/dev/null 2>&1

— whoami

Należy podkreślić, że strona, o której mówisz, jest częścią Podręcznika użytkownika Bash . To oczywiście opisuje bash . Istnieją inne powłoki na świecie, inne niż bash, &>i >&(gdy nie są używane w kontekście 2>&1lub>&2 , etc.) atakujących-izmy i nie są standardowe . Nie należy ich używać w skryptach powłoki, które mają być przenośne.

— G-Man mówi „Reinstate Monica”