> & [FILE_DESCRIPTOR] vs> & opérateurs de redirection de fichier bash
J'ai lu sur la redirection bash, et j'ai rencontré ces deux articles à ce sujet
Premier :
https://www.brianstorti.com/understanding-shell-script-idiom-redirect
indiquant que
Vous pouvez utiliser & [FILE_DESCRIPTOR] pour référencer une valeur de descripteur de fichier;
cependant quand je le lisais simultanément avec le deuxième article
deuxième
https://catonmat.net/bash-one-liners-explained-part-three
il a déclaré que
Notez également que dans bash, en écrivant ceci:
$ command &>fileEst exactement le même que:
$ command >&fileLa première forme est cependant préférée.
comment se fait-il >&filecréer fileun descripteur de fichier
Réponses
Ce sont en fait deux opérateurs différents qui sont en conflit l'un avec l'autre, un du shell Bourne, un du shell C.
cmd >&2
Court pour
cmd 1>&2
L'opérateur Bourne shell qui s'exécute cmdavec son stdout (fd 1) connecté à la même ressource (même description de fichier ouvert ) que celui de fd 2 ( x>&y(ou x<&yqui est exactement le même) redirige fd x vers la même ressource que sur fd y ).
cmd >& file
Est l' cshopérateur C shell ( ) qui s'exécute cmdavec ses fd 1 et 2 connectés à une nouvelle description de fichier ouverte obtenue en ouvrant fileen mode écriture seule. Dans la syntaxe Bourne shell, l'équivalent seraitcmd > file 2>&1
Ils font des conflits. Celui qui est réellement utilisé dépend du fait que la cible est numérique ou non.
Si tu as:
cmd >&"$file"
L'opérateur Bourne shell sera utilisé s'il $filecontient une séquence de chiffres décimaux et l'opérateur C shell sera utilisé autrement!
C'est pourquoi il vaut mieux éviter cet opérateur csh et utiliser la syntaxe Bourne shell ( > file 2>&1) à la place.
bash(and zsh) a également un &>opérateur comme alternative à >&, mais notez qu'il rompt la conformité POSIX comme il cmd &> fileest censé s'exécuter cmd &puis > filedans POSIX sh. Il n'a cependant pas le problème de conflit mentionné ci-dessus.