Je vois des choses comme command 1> out
ou avec 2>&1
pour rediriger stderr, mais parfois, je vois aussi &>
seul, etc.
Quelle est la meilleure façon de comprendre &
et ce que cela signifie exactement?
Le &
dans 2>&1
indique simplement que le nombre 1
est un descripteur de fichier et non un nom de fichier. Dans ce cas, le standard output file descriptor
.
Si vous utilisez 2>1
, les erreurs seront redirigées vers un fichier appelé 1
, mais si vous utilisez 2>&1
, vous l'enverriez au standard output stream
.
Ce &>
dit d'envoyer les deux, standard output
et standard error
, quelque part. Par exemple, ls <non-existent_file> &> out.file
. Laissez-moi illustrer ceci avec un exemple.
Installer:
Créez un fichier koko
avec le contenu suivant:
#!bin/bash
ls j1
echo "koko2"
Rendez-le exécutable: chmod u+x koko
Notez maintenant que j1
n'existe pas
Maintenant, lancez ./koko &> output
lancez cat output
et vous verrez
ls: cannot access 'j1': No such file or directory
koko2
standard error
(ls: cannot access 'j1': No such file or directory
) et standard output
(koko2
) ont été envoyés dans le fichier output
.
Maintenant, lancez-le à nouveau, mais cette fois-ci,
./koko > output
Faites cat output
et vous ne verrez que le koko2
like. Mais pas la sortie d'erreur de la commande ls j1
. Cela sera envoyé au standard error
que vous verrez dans votre terminal.
Note importante grâce à @Byte Commander:
Notez que dans command >file 2>&1
l'ordre de la redirection est important. Si vous écrivez plutôt command 2>&1 >file
(ce qui n’est normalement pas ce que vous voulez), il va tout d’abord rediriger le stdout
de la commande vers le fichier, puis rediriger le stderr
de la commande vers son stdout
maintenant inutilisé. ou le rediriger à nouveau, mais il ne sera pas écrit dans le fichier.
> FILE 2>&1
et &> FILE
sont équivalents. Voir 8.2.3.2. Réorientation des erreurs de in Guide Bash pour les débutants, chapitre 8
Le [n]>&Word
est appelé descripteur de fichier de sortie en double (voir section 2.7.6 de POSIX Shell Language Standard). Ce comportement particulier est caractéristique des coques de type bourne, notamment ksh
, dash
et bash
; En fait, la norme est basée sur Bourne Shell et ksh
. En examinant les manuels tcsh et csh , ils ne permettent apparemment pas de dupliquer les descripteurs de fichier. Toutefois, d'après la description de >&
, il se comporte comme &>
dans bash
(c'est-à-dire, redirige les erreurs et la sortie normale vers le fichier).
Dans les systèmes similaires à * nix, y compris Ubuntu, vous entendez souvent que tout est un 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>&1
signifie techniquement le descripteur de fichier dupliqué 2 sur le descripteur de fichier 1. En d'autres termes, cette réponse :
2> & 1 indique au shell de donner à la commande un descripteur de fichier 2 qui est une copie du descripteur 1. (c.-à-d. Que stderr & stdout pointe sur same fd).
La clé ici est de noter que le descripteur 1 doit être défini en premier. Étant donné que Shell traite les redirections de gauche à droite, le command >FILE 2>&1
indique à Shell de rewire stdout pour que command
entre en premier dans FILE
, et seul le descripteur 2 devient alors la copie de 1, c'est-à-dire 1 et 2 points vers le même emplacement - FILE
.
Ceci va bien au-delà de l'erreur standard et de la sortie standard. Comme indiqué dans cette réponse , en faisant 3&>2
... vous dupliquez (dup2) archiveur 2 sur archiveur 3, en fermant éventuellement l'archivage 3 s'il est déjà ouvert
Exemple de manipulation de descripteurs de fichier, parmi beaucoup, serait capture du résultat de la commande dialog
dans une variable
Il convient également de noter que &>
est spécifique à bash
. Dans zsh
, cela se comporte de la même manière mais, d’après la documentation, "... n’a pas le même effet que"> Word 2> & 1 "en présence de multios". Dans le code /bin/sh
compatible POSIX, il s'agirait d'une redirection normale avec la commande en arrière-plan. Voir aussi, Existe-t-il un code sh qui n'est pas du code bash syntaxiquement valide? .
Voir également: