Différences de redirection entre &>> & et 2> & 1

Sur ce thread SO et quelques autres threads, j'ai vu les commandes suivantes pour rediriger stdoutet stderrvers un fichier.

Sont-ils tous équivalents? Y a-t-il une différence entre eux?

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

Puisque vous avez tagué zsh, permettez-moi de vous dire que les 3 redirections fonctionnent exactement de la même manière. Comme vous avez pu lire dans les deux postes en double (celui du commentaire et celui de votre poste), ils ont tous redirect stderrà stdoutqui à leur tour est redirigé vers le fichier « logfile » (c. -à le fichier journal contiendra à la fois la sortie et les erreurs ).

Mais leur comportement change beaucoup en fonction du shell dans lequel vous vous trouvez.

Les trois styles de redirections fonctionnent bien de la même manière bashetzsh

Mais:

Fonctionne uniquement >&dans cshoutcsh

[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 ~]$

En travaux kshuniquement 2>&1.

$ ./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

Je déteste ksh. Alors qu'il >&vient de donner une erreur, l' &>arrière - plan a fait une partie de la commande et a vidé le fichier journal (s'il n'est pas vide).

&>et >&semi-équivalence (clobber)

La zshsection des redirections manuelles indique que:

• &>
• >&

sont équivalents.

Les deux vont encombrer le fichier - tronquer le fichier à 0 octet avant d'écrire dessus, comme ce > fileserait le cas dans le cas STDIN uniquement.

Cependant , la bashsection des redirections manuelles ajoute que:

Des deux formes, la première est préférée. C'est sémantiquement équivalent à

>word 2>&1

Lorsque vous utilisez le deuxième formulaire, le mot peut ne pas se développer en un nombre ou -. Si tel est le cas, d'autres opérateurs de redirection s'appliquent (voir Duplication des descripteurs de fichiers ci-dessous) pour des raisons de compatibilité.

Ainsi, pendant que vous balisez zsh, il est probablement judicieux d'obtenir la mémoire des doigts sous la première forme si jamais vous écriviez un bashscript.

>> logfile 2>&1et &>>équivalence (en annexe)

Ici, logfilen'est pas écrasé, mais ouvert pour l'écriture à la fin du fichier, c'est-à-dire en mode ajout ( O_APPEND).

L'équivalent dans les deux {ba,z}shest:

command1 &>> logfile

Dans bash:

Le format pour ajouter la sortie standard et l'erreur standard est:

&>>word

C'est sémantiquement équivalent à

>>word 2>&1

(voir Duplication des descripteurs de fichiers ci-dessous).

(Remarque: l'utilisation clobber de &>over >&dans la section ci-dessus est à nouveau recommandée étant donné qu'il n'y a qu'une seule façon de l'ajouter bash.)

zshpermet à la fois &>>et >>&formes.