Co dokładnie oznacza i oznacza przekierowanie danych wyjściowych?

Widzę rzeczy takie jak command 1> outlub z 2>&1przekierowaniem stderr, ale czasami też widzę &>sam, itp.

Jaki jest najlepszy sposób na zrozumienie &i co to dokładnie znaczy?

&W 2>&1po prostu mówi, że liczba 1jest deskryptor pliku, a nie nazwa pliku. W tym przypadku standard output file descriptor.

Jeśli użyjesz 2>1, przekieruje to błędy do pliku o nazwie, 1ale jeśli użyjesz 2>&1, wyśle ​​to do standard output stream.

To oznacza, &>że wyślij oba standard outputi standard errorgdzieś. Na przykład ls <non-existent_file> &> out.file. Pozwól, że zilustruję to przykładem.

Ustawiać:

1. Utwórz plik kokoo następującej treści:

   #!bin/bash
   
   ls j1
   echo "koko2"
   

2. Spraw, by był wykonywalny: chmod u+x koko

3. Teraz zauważ, że j1nie istnieje

4. Teraz biegnij ./koko &> output

5. biegnij, cat outputa zobaczysz

   ls: cannot access 'j1': No such file or directory
   koko2
   

Zarówno standard error( ls: cannot access 'j1': No such file or directory), jak i standard output( koko2) zostały wysłane do pliku output.

Teraz uruchom go ponownie, ale tym razem tak:

./koko > output

Zrób, cat outputa zobaczysz tylko koko2podobne. Ale nie błąd wyjściowy z ls j1polecenia. Zostanie on wysłany do tego, standard errorco zobaczysz w swoim terminalu.

Ważna uwaga dzięki @Byte Commander:

Pamiętaj, że command >file 2>&1kolejność przekierowań jest ważna. Jeśli command 2>&1 >filezamiast tego napiszesz (co zwykle nie jest tym, czego chcesz), najpierw przekieruje polecenie stdoutdo pliku, a następnie przekieruje polecenie stderrdo teraz nieużywanego stdout, więc pojawi się w terminalu i możesz potokować go lub przekierować ponownie, ale nie zostanie zapisany w pliku.

> FILE 2>&1i &> FILEsą równoważne. Patrz 8.2.3.2. Przekierowanie błędów w Bash Guide dla początkujących Rozdział 8

[n]>&wordNazywa powielania wyjściowego pliku deskryptora (patrz punkt 2.7.6 z POSIX Shell Język standardu). To szczególne zachowanie funkcji Bourne jak powłoki, w tym ksh, dashoraz bash; w rzeczywistości standard opiera się na powłoce Bourne'a i ksh. Patrząc na tcsh podręczniki i csh , najwyraźniej nie zapewniają one możliwości kopiowania żadnego deskryptora pliku, jednak z opisu >&, zachowuje się jak &>w bash(to znaczy przekierowuje błędy i normalne wyjście do pliku).

W systemach * nix, w tym Ubuntu, często słyszysz, że wszystko jest w formie pliku, a raczej deskryptorem pliku . Standardowym wyjściem jest stały deskryptor pliku 1, a standardowym błędem jest deskryptor pliku 2. Tak więc > FILE 2>&1technicznie oznacza duplikowanie deskryptora pliku 2 na deskryptorze pliku 1. Innymi słowy tej odpowiedzi :

2> i 1 nakazuje powłoce nadanie komendzie deskryptora pliku 2, który jest duplikatem deskryptora 1. (tzn. Stderr i stdout wskazują na to samo fd).

Kluczem tutaj jest zauważyć, że deskryptor 1 musi być ustawiony jako pierwszy. Ponieważ powłoka przetwarza przekierowania w kolejności od lewej do prawej,command >FILE 2>&1 mówi powłoce, aby przełączyła standardowe wyjście, commandaby przejść do FILEpierwszej, a dopiero potem deskryptor 2 może stać się kopią 1, to znaczy 1 i 2 wskazują tę samą lokalizację - FILE.

To oczywiście wykracza poza standardowy błąd i standardowe wyjście. Jak pokazano w tej odpowiedzi , robiąc3&>2

... duplikujesz (dup2) filedescritor 2 na filedescriptor 3, ewentualnie zamykając filedescriptor 3, jeśli jest już otwarty

Przykładem manipulacji deskryptorami plików, wśród wielu, byłoby przechwytywanie danych wyjściowychdialog polecenia w zmiennej

Warto również zauważyć, że &>jest to specyficzne dla bash. W zshtym zachowuje się tak samo, ale zgodnie z dokumentacją „... nie ma takiego samego efektu jak„> słowo 2> i 1 ”w obecności multios”. W zgodności z POSIX /bin/shbyłoby to traktowane jako zwykłe przekierowanie z umieszczeniem polecenia w tle. Zobacz też, Czy istnieje kod sh, który nie jest poprawnym składniowo kodem bash? .

Zobacz też:

• Greg's Wiki: Deskryptory plików