Różnice przekierowań między &>> i i 2> i 1

W tym wątku SO i kilku innych wątkach widziałem następujące polecenia przekierowujące stdouti stderrdo pliku.

Czy wszystkie są równoważne? Czy jest jakaś różnica między nimi?

command1 >> logfile 2>&1
command &> logfile
command >& logfile

Ponieważ otagowałeś zsh, powiem ci, że wszystkie 3 przekierowania działają dokładnie w ten sam sposób. Jak mogłeś przeczytać w dwóch zduplikowanych postach (tym w komentarzu i tym w swoim poście), wszystkie one przekierowują, stderrdo stdoutktórego inturn jest przekierowywany do pliku „logfile” (tzn. Plik dziennika będzie zawierał zarówno dane wyjściowe, jak i błędy ).

Ale ich zachowanie zmienia się DUŻO w zależności od powłoki, w której się znajdujesz.

Wszystkie trzy style przekierowań działają dobrze w ten sam sposób w bashizsh

Ale:

>&Działa tylko w cshlubtcsh

[soum@server ~]$  ./test.sh > logfile 2>&1
Ambiguous output redirect.
[soum@server ~]$ ./test.sh &> logfile
Invalid null command.
[soum@server ~]$ ./test.sh >& logfile
[soum@server ~]$ echo $SHELL
/bin/tcsh
[soum@server ~]$

W kshzaledwie 2>&1prac.

$ ./test.sh >& logfile
-ksh: logfile: bad file unit number
$ ./test.sh &> logfile
[1]     23039
$ 1  2  3  4  5  6  logfile  test.sh
ls: cannot access ttr: No such file or directory

[1] +  Done(2)                 ./test.sh &> logfile

Nienawidzę ksh. Podczas gdy >&tylko dał błąd, &>część polecenia w tle została opróżniona i opróżniono plik dziennika (jeśli nie jest pusty).

&>i >&pół-równoważność (clobber)

Sekcja zshRęczne przekierowania mówi, że:

• &>
• >&

są równoważne.

Oba zablokują plik - skracają go do 0 bajtów przed zapisem, podobnie jak > filew przypadku tylko STDIN.

Jednak The bashobsługi sekcja przekierowania dodaje, że:

Spośród dwóch form preferowana jest pierwsza. Jest to semantycznie równoważne z

>word 2>&1

Podczas korzystania z drugiego formularza słowo nie może rozwinąć się do liczby lub -. Jeśli tak jest, zastosowanie mają inne operatory przekierowania (patrz Powielanie deskryptorów plików poniżej) ze względu na kompatybilność.

Tak więc, podczas gdy tagujesz zsh, prawdopodobnie dobrą praktyką jest zdobywanie pamięci palców w pierwszej formie, jeśli kiedykolwiek napiszesz bashskrypt.

>> logfile 2>&1i &>>równoważność (dołącz)

Tutaj logfilenie jest nadpisywany, ale otwarty do zapisu na końcu pliku, tj. Append mode ( O_APPEND).

Odpowiednikiem obu {ba,z}shjest:

command1 &>> logfile

W bash:

Format dołączania standardowego wyjścia i standardowego błędu to:

&>>word

Jest to semantycznie równoważne z

>>word 2>&1

(patrz Powielanie deskryptorów plików poniżej).

(Uwaga: użycie clobber &>over >&w powyższej sekcji jest ponownie zalecane, ponieważ istnieje tylko jeden sposób dołączenia bash.)

zshdopuszcza zarówno formy, jak &>>i >>&formy.