Que signifie & signifie exactement dans la redirection de sortie?

Je vois des trucs comme command 1> outou avec 2>&1pour rediriger stderr, mais parfois je vois aussi tout &>seul, etc.

Quelle est la meilleure façon de comprendre &et ce que cela signifie exactement?

L' &en 2>&1dit simplement que le numéro 1est un descripteur de fichier et non un nom de fichier. Dans ce cas, le standard output file descriptor.

Si vous utilisez 2>1, cela redirigerait les erreurs vers un fichier appelé 1mais si vous utilisez 2>&1, il l'enverrait au standard output stream.

Cela &>dit envoyer les deux standard outputet standard errorquelque part. Par exemple, ls <non-existent_file> &> out.file. Permettez-moi d'illustrer cela avec un exemple.

Installer:

1. Créez un fichier kokoavec le contenu suivant:

   #!bin/bash
   
   ls j1
   echo "koko2"
   

2. Rendez-le exécutable: chmod u+x koko

3. Notez maintenant que cela j1n'existe pas

4. Maintenant, lancez ./koko &> output

5. cours cat outputet tu verras

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

Les deux, standard error( ls: cannot access 'j1': No such file or directory) et standard output( koko2), ont été envoyés au fichier output.

Maintenant, exécutez-le à nouveau, mais cette fois comme ceci:

./koko > output

Faites cat outputet vous ne verrez que koko2similaires. Mais pas la sortie d'erreur de la ls j1commande. Celui-ci sera envoyé à celui standard errorque vous verrez dans votre terminal.

Remarque importante grâce à @Byte Commander:

Notez que dans command >file 2>&1l'ordre de la redirection est important. Si vous écrivez à la command 2>&1 >fileplace (ce qui n'est normalement pas ce que vous voulez), il redirigera d'abord les commandes stdoutvers le fichier et ensuite redirigera les commandes stderrvers celles qui ne sont plus utilisées stdout, il s'affichera donc dans le terminal et vous pourrez le rediriger ou le rediriger à nouveau, mais il ne sera pas écrit dans le fichier.

> FILE 2>&1et &> FILEsont équivalents. Voir 8.2.3.2. Redirection des erreurs de dans Bash Guide for Beginners Chapter 8

Il [n]>&words’appelle Duplicating Output File Descriptor (voir la section 2.7.6 de POSIX Shell Language Standard). Ce comportement particulier est caractéristique de bourne comme des obus, y compris ksh, dashet bash; en fait, la norme est basée sur le shell Bourne et ksh. En regardant dans les manuels tcsh et csh , ils ne fournissent apparemment pas la possibilité de dupliquer un descripteur de fichier, mais à partir de la description de >&, cela se comporte comme &>dans bash(c'est-à-dire, redirige les erreurs et la sortie normale vers le fichier).

Dans les systèmes de type * nix, y compris Ubuntu, vous entendez souvent que tout est fichier, ou plutôt un descripteur de fichier . La sortie standard est le descripteur de fichier constant 1 et l'erreur standard est le descripteur de fichier 2. Donc, > FILE 2>&1techniquement, cela signifie un descripteur de fichier en double 2 sur le descripteur de fichier 1. En d'autres termes de cette réponse :

Le 2> & 1 indique au shell de donner à la commande un descripteur de fichier 2 qui est un double du descripteur 1. (c'est-à-dire que stderr et stdout pointent vers le même fd).

La clé ici est de noter que le descripteur 1 doit être défini en premier. Parce que le shell traite les redirections dans l'ordre de gauche à droite, le command >FILE 2>&1shell dit de recâbler la sortie standard pour commandentrer en FILEpremier, et alors seulement le descripteur 2 peut devenir une copie de 1, c'est-à-dire que 1 et 2 pointent vers le même emplacement - FILE.

Cela va bien sûr au-delà de l'erreur standard et de la sortie standard. Comme le montre cette réponse , en faisant3&>2

... vous dupliquez (dup2) filedescritor 2 sur filedescriptor 3, fermant éventuellement filedescriptor 3 s'il est déjà ouvert

Un exemple de manipulation de descripteurs de fichiers, parmi beaucoup d'autres, serait de capturer la sortie de la dialogcommande dans une variable

Il convient également de noter que cela &>est spécifique à bash. Dans zshce cas, se comporte de la même manière, mais selon la documentation, "... n'a pas le même effet que '> mot 2> & 1' en présence de multios". En conformité POSIX /bin/sh, cela serait traité comme une redirection régulière avec mise en arrière-plan de la commande. Voir aussi, Existe - t-il un code sh qui n'est pas un code bash syntaxiquement valide? .

Voir également:

• Wiki de Greg: Descripteurs de fichiers