Dans le shell, que signifie «2> & 1»?


2285

Dans un shell Unix, si je veux combiner stderret stdoutdans le stdoutflux pour une manipulation ultérieure, je peux ajouter ce qui suit à la fin de ma commande:

2>&1

Donc, si je veux utiliser headsur la sortie de g++, je peux faire quelque chose comme ceci:

g++ lots_of_errors 2>&1 | head

donc je ne peux voir que les premières erreurs.

J'ai toujours du mal à m'en souvenir, et je dois constamment chercher, et c'est principalement parce que je ne comprends pas bien la syntaxe de cette astuce particulière.

Quelqu'un peut-il diviser cela et expliquer ce que 2>&1 signifie caractère par caractère ?


50
@dbr Je ne pense pas que ce soit juste un coup bash - je crois que c'est un truc bourne shell; d'où sh, bash, ksh, ash, dash, etc.
pistolets

8
Cela fait partie du paragraphe de redirection décrivant les shells compatibles POSIX, ou shell POSIX pour faire court. ksh est un shell POSIX par exemple. Voir: pubs.opengroup.org/onlinepubs/009695399/utilities/…
jim mcnamara

12
Cette construction fonctionne également sur Windows.
Vadzim

2
C'est généralement mieux 2>&1que 2> / dev / null ;-)
F. Hauri

11
Je pensais que je mentionnerais que |& c'est un raccourci pour 2>&1 |si vous utilisez zsh. Je ne peux pas dire si cela s'applique à d'autres coquilles de type bourne ou si c'est une fonctionnalité uniquement zsh.
chrixian

Réponses:


2557

Le descripteur de fichier 1 est la sortie standard ( stdout).
Le descripteur de fichier 2 est l'erreur standard ( stderr).

Voici une façon de se souvenir de cette construction (bien qu'elle ne soit pas entièrement exacte): au début, cela 2>1peut sembler être un bon moyen de rediriger stderrvers stdout. Cependant, il sera en fait interprété comme "rediriger stderrvers un fichier nommé 1". &indique que ce qui suit est un descripteur de fichier et non un nom de fichier. Ainsi , la construction devient: 2>&1.


281
mais ne devrait-il pas plutôt l'être &2>&1?
dokaspar

319
@Dominik: Non, &n'est interprété que comme signifiant "descripteur de fichier" dans le contexte des redirections. L'écriture command &2>&est analysée comme command &et 2>&1, c'est-à-dire "exécuter commanden arrière-plan, puis exécuter la commande 2et rediriger sa sortie standard vers sa sortie standard".
Adam Rosenfield

15
Pourquoi ont-ils choisi des trucs aussi mystérieux que celui-ci? Juste curieux.
CommaToast

81
Mais comment redirigeriez-vous stderr vers un fichier nommé '& 1'?
Martín Fixman

120
@Martin:2>'&1'

632
echo test > afile.txt

redirige stdout vers afile.txt. C'est la même chose que de faire

echo test 1> afile.txt

Pour rediriger stderr, vous faites:

echo test 2> afile.txt

>& est la syntaxe pour rediriger un flux vers un autre descripteur de fichier - 0 est stdin, 1 est stdout et 2 est stderr.

Vous pouvez rediriger stdout vers stderr en faisant:

echo test 1>&2 # or echo test >&2

Ou vice versa:

echo test 2>&1

Donc, en bref ... 2>redirige stderr vers un fichier (non spécifié), en ajoutant &1redirige stderr vers stdout.


5
est-ce que cela a un sens pour vous java ... 2&1 >> data.log, j'ai vu un de mes collègues faire ça?
Thang Pham

5
@Harry qui ressemble à un shell qui n'est pas bash, ou à une faute de frappe .. cmd 2>&1 >> somefile.logajoutera stdout / stderr à un fichier - c'est fondamentalement la même que ci-dessus, avec >> fileà ajouter
dbr

73
@dbr cmd 2>&1 >>filene redirige pas stderr vers le fichier, mais le cmd >> file 2>&1fait. L'ordre est important. Dans le premier cas, stderr est redirigé vers la sortie standard du shell (éventuellement un tty si la commande est entrée de manière interactive), puis la sortie standard est dirigée vers le fichier. Dans le second cas, stdout est dirigé vers le fichier, puis stderr est dirigé vers le même endroit.
William Pursell

2
J'aime la réponse ci-dessus, mais cela pourrait être plus clair. "2> & 1" redirige stderr vers la cible de stdout. Donc, si vous avez quelque chose comme "ls -l >> directoryContents 2> & 1" Le résultat sera un fichier nommé directoryContents auquel sera ajouté le contenu du répertoire de travail. S'il y a des erreurs dans l'exécution: les messages d'erreur seront également ajoutés au fichier directoryContents au fur et à mesure qu'ils se produisent.
Max West

1
Est 0(or 1,2)>&0(or 1,2)comme une option pour contrôler la sortie? C'est echo test >test.log 2>&1pareil echo test 2>&1 >test.log?
Simin Jie

318

Quelques astuces sur la redirection

Certaines particularités de syntaxe à ce sujet peuvent avoir des comportements importants. Il y a quelques petits échantillons sur les redirections, STDERR, STDOUTet arguments commande .

1 - Écraser ou ajouter?

Symbole >signifie redirection .

  • >signifie envoyer dans un fichier complet , écraser la cible si elle existe (voir la noclobberfonction bash au n ° 3 plus tard).
  • >>signifie envoyer en plus de s'ajouterait à la cible s'il existe.

Dans tous les cas, le fichier serait créé s'il n'existait pas.

2 - La ligne de commande du shell dépend de l'ordre !!

Pour tester cela, nous avons besoin d' une commande simple qui enverra quelque chose sur les deux sorties :

$ ls -ld /tmp /tnt
ls: cannot access /tnt: No such file or directory
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt 2>/dev/null
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

(En supposant que vous n'ayez pas de répertoire nommé /tnt, bien sûr;). Eh bien, nous l'avons !!

Voyons donc:

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1

$ ls -ld /tmp /tnt 2>&1 >/dev/null
ls: cannot access /tnt: No such file or directory

La dernière ligne de commande se décharge STDERRsur la console, et cela ne semble pas être le comportement attendu ... Mais ...

Si vous souhaitez effectuer un post-filtrage sur une sortie, l'autre ou les deux:

$ ls -ld /tmp /tnt | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt 2>&1 | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt >/dev/null | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1 | sed 's/^.*$/<-- & --->/'

$ ls -ld /tmp /tnt 2>&1 >/dev/null | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->

Notez que la dernière ligne de commande de ce paragraphe est exactement la même que dans le paragraphe précédent, où j'ai écrit ne semble pas être le comportement attendu (donc, cela pourrait même être un comportement attendu).

Eh bien, il y a quelques astuces sur les redirections, pour effectuer différentes opérations sur les deux sorties :

$ ( ls -ld /tmp /tnt | sed 's/^/O: /' >&9 ) 9>&2  2>&1  | sed 's/^/E: /'
O: drwxrwxrwt 118 root root 196608 Jan  7 12:13 /tmp
E: ls: cannot access /tnt: No such file or directory

Nota: le &9descripteur se produirait spontanément à cause de ) 9>&2.

Addendum: nota! Avec la nouvelle version de( >4.0) il y a une nouvelle fonctionnalité et une syntaxe plus sexy pour faire ce genre de choses:

$ ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /')
O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
E: ls: cannot access /tnt: No such file or directory

Et enfin pour un tel formatage de sortie en cascade:

$ ((ls -ld /tmp /tnt |sed 's/^/O: /' >&9 ) 2>&1 |sed 's/^/E: /') 9>&1| cat -n
     1  O: drwxrwxrwt 118 root root 196608 Jan  7 12:29 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

Addendum: nota! Même nouvelle syntaxe, dans les deux sens:

$ cat -n <(ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /'))
     1  O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

STDOUTpasser par un filtre spécifique, STDERRà un autre et enfin les deux sorties fusionnées passent par un troisième filtre de commande.

3 - Un mot sur l' noclobberoption et la >|syntaxe

Il s'agit d' écraser :

Tout en set -o noclobberdemandant à bash de ne pas écraser de fichier existant, la >|syntaxe vous permet de passer par cette limitation:

$ testfile=$(mktemp /tmp/testNoClobberDate-XXXXXX)

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:15 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:19 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:21 CET 2013

Le fichier est écrasé à chaque fois, enfin maintenant:

$ set -o noclobber

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

Passer avec >|:

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:18:58 CET 2013

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:19:01 CET 2013

Désactiver cette option et / ou demander si elle est déjà définie.

$ set -o | grep noclobber
noclobber           on

$ set +o noclobber

$ set -o | grep noclobber
noclobber           off

$ date > $testfile ; cat $testfile
Mon Jan  7 13:24:27 CET 2013

$ rm $testfile

4 - Dernière astuce et plus ...

Pour rediriger les deux sorties d'une commande donnée, nous voyons qu'une bonne syntaxe pourrait être:

$ ls -ld /tmp /tnt >/dev/null 2>&1

pour ce cas particulier , il existe une syntaxe de raccourci: &>... ou>&

$ ls -ld /tmp /tnt &>/dev/null

$ ls -ld /tmp /tnt >&/dev/null

Nota: si elle 2>&1existe, 1>&2est une syntaxe correcte aussi:

$ ls -ld /tmp /tnt 2>/dev/null 1>&2

4b- Maintenant, je vais vous laisser réfléchir sur:

$ ls -ld /tmp /tnt 2>&1 1>&2  | sed -e s/^/++/
++/bin/ls: cannot access /tnt: No such file or directory
++drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

$ ls -ld /tmp /tnt 1>&2 2>&1  | sed -e s/^/++/
/bin/ls: cannot access /tnt: No such file or directory
drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

4c- Si vous souhaitez plus d' informations

Vous pouvez lire le bon manuel en cliquant sur:

man -Len -Pless\ +/^REDIRECTION bash

dans un console ;-)


5
Pour en savoir plus: Si vous avez aimé cela, vous pouvez apprécier: Comment l'abus de redirection peut donner des comportements étranges
F. Hauri


130

J'ai trouvé ce brillant article sur la redirection: Tout sur les redirections

Redirige la sortie standard et l'erreur standard vers un fichier

$ commande &> fichier

Ce one-liner utilise l' &>opérateur pour rediriger les deux flux de sortie - stdout et stderr - de la commande vers le fichier. Il s'agit du raccourci de Bash pour rediriger rapidement les deux flux vers la même destination.

Voici à quoi ressemble la table des descripteurs de fichiers après que Bash a redirigé les deux flux:

Entrez la description de l'image ici

Comme vous pouvez le voir, stdout et stderr pointent maintenant vers file. Donc, tout ce qui est écrit sur stdout et stderr est écrit file.

Il existe plusieurs façons de rediriger les deux flux vers la même destination. Vous pouvez rediriger chaque flux l'un après l'autre:

$ command> fichier 2> & 1

Il s'agit d'un moyen beaucoup plus courant de rediriger les deux flux vers un fichier. La première stdout est redirigée vers le fichier, puis stderr est dupliqué pour être identique à la stdout. Donc, les deux flux finissent par pointer vers file.

Lorsque Bash voit plusieurs redirections, il les traite de gauche à droite. Passons en revue les étapes et voyons comment cela se produit. Avant d'exécuter des commandes, la table des descripteurs de fichiers de Bash ressemble à ceci:

Entrez la description de l'image ici

Maintenant, Bash traite le premier fichier de redirection>. Nous avons déjà vu cela auparavant et cela rend stdout point à déposer:

Entrez la description de l'image ici

Bash suivant voit la deuxième redirection 2> & 1. Nous n'avons jamais vu cette redirection auparavant. Celui-ci duplique le descripteur de fichier 2 pour être une copie du descripteur de fichier 1 et nous obtenons:

Entrez la description de l'image ici

Les deux flux ont été redirigés vers un fichier.

Attention cependant ici! L'écriture

commande> fichier 2> & 1

n'est pas la même chose que d'écrire:

$ commande 2> & 1> fichier

L'ordre des redirections est important dans Bash! Cette commande redirige uniquement la sortie standard vers le fichier. Le stderr continuera d'imprimer sur le terminal. Pour comprendre pourquoi cela se produit, reprenons les étapes. Donc, avant d'exécuter la commande, la table des descripteurs de fichiers ressemble à ceci:

Entrez la description de l'image ici

Maintenant, Bash traite les redirections de gauche à droite. Il voit d'abord 2> & 1 donc il duplique stderr en stdout. Le tableau des descripteurs de fichiers devient:

Entrez la description de l'image ici

Bash voit maintenant la deuxième redirection >file, et il redirige stdout vers le fichier:

Entrez la description de l'image ici

Voyez-vous ce qui se passe ici? Stdout pointe maintenant vers le fichier, mais le stderr pointe toujours vers le terminal! Tout ce qui est écrit sur stderr est toujours imprimé à l'écran! Soyez donc très, très prudent avec l'ordre des redirections!

Notez également que dans Bash, l'écriture

$ commande &> fichier

est exactement le même que:

$ commande> & fichier


3
Les deux derniers sont différents si "commande" se termine par un nombre, car alors cela est pris comme descripteur de fichier facultatif pour>&
MM

Très beau dessin et explication! Pourriez-vous expliquer ce que signifie réellement "dupliquer"? Vous avez mentionné: "Celui-ci [2> & 1] duplique le descripteur de fichier 2 pour être une copie du descripteur de fichier 1". Il semble que stderr soit dupliqué sur stdout. Mais si c'est le cas, devrais-je également voir une erreur /dev/tty0?
HCSF

87

Les nombres se réfèrent aux descripteurs de fichiers (fd).

  • Zéro est stdin
  • L'un est stdout
  • Deux est stderr

2>&1 redirige fd 2 vers 1.

Cela fonctionne pour n'importe quel nombre de descripteurs de fichiers si le programme les utilise.

Vous pouvez regarder /usr/include/unistd.hsi vous les oubliez:

/* Standard file descriptors.  */
#define STDIN_FILENO    0   /* Standard input.  */
#define STDOUT_FILENO   1   /* Standard output.  */
#define STDERR_FILENO   2   /* Standard error output.  */

Cela dit, j'ai écrit des outils C qui utilisent des descripteurs de fichiers non standard pour la journalisation personnalisée afin que vous ne le voyiez pas sauf si vous le redirigez vers un fichier ou quelque chose.


58

Cette construction envoie le flux d'erreur standard ( stderr) à l' emplacement actuel de la sortie standard ( stdout) - ce problème de devise semble avoir été négligé par les autres réponses.

Vous pouvez rediriger n'importe quel descripteur de sortie vers un autre en utilisant cette méthode, mais elle est le plus souvent utilisée pour canaliser stdoutet stderrdiffuser en un seul flux pour le traitement.

Quelques exemples sont:

# Look for ERROR string in both stdout and stderr.
foo 2>&1 | grep ERROR

# Run the less pager without stderr screwing up the output.
foo 2>&1 | less

# Send stdout/err to file (with append) and terminal.
foo 2>&1 |tee /dev/tty >>outfile

# Send stderr to normal location and stdout to file.
foo >outfile1 2>&1 >outfile2

Notez que ce dernier ne dirigera passtderr vers outfile2- il le redirige vers ce qui stdoutétait lorsque l'argument a été rencontré ( outfile1), puis redirige stdoutvers outfile2.

Cela permet une supercherie assez sophistiquée.


5
Bien que ce dernier exemple soit beaucoup plus clair: foo> outfile2 2> outfile1
Michael Cramer

3
Plus clair, oui, mais cela ne montrerait pas la nature "positionnelle" de la redirection. L'exemple est artificiel car il n'est généralement pas utile de le faire sur une seule ligne - la méthode devient vraiment utile lorsque différentes parties sont responsables des différentes parties de la redirection. Par exemple, lorsqu'un script effectue un bit de redirection et que vous l'exécutez avec un autre bit.
paxdiablo

5
Je viens de réaliser que le dernier exemple résout également une confusion de longue date que j'avais au sujet de pourquoi cela: some_program 2>&1 > /dev/nullne fonctionne pas comme ça: some_program > /dev/null 2>&1.
snapfractalpop

Votre commentaire sur le dernier exemple vaut ses lettres en or :-) Je n'ai jamais pensé que ces arguments redirectionnels sont positionnels ... Je pense que c'est assez important à savoir.
Nils-o-mat

20

2>&1est une construction shell POSIX. Voici une ventilation, jeton par jeton:


2: Descripteur de fichier de sortie " Erreur standard ".

>&: Dupliquez un opérateur de descripteur de fichier de sortie (une variante de l' opérateur de redirection de sortie> ). Étant donné [x]>&[y], le descripteur de fichier indiqué par xest fait pour être une copie du descripteur de fichier de sortie y.

1« Sortie standard descripteur de fichier de sortie ».

L'expression 2>&1copie le descripteur de fichier 1à l'emplacement 2, de sorte que toute sortie écrite dans 2("erreur standard") dans l'environnement d'exécution va dans le même fichier décrit à l'origine par 1("sortie standard").


Plus d'explications:

Descripteur de fichier : "Un entier unique, non négatif par processus, utilisé pour identifier un fichier ouvert à des fins d'accès au fichier."

Sortie / erreur standard : reportez-vous à la remarque suivante dans la section Redirection de la documentation du shell:

Les fichiers ouverts sont représentés par des nombres décimaux commençant par zéro. La plus grande valeur possible est définie par l'implémentation; cependant, toutes les implémentations doivent prendre en charge au moins 0 à 9, inclus, pour une utilisation par l'application. Ces nombres sont appelés "descripteurs de fichiers". Les valeurs 0, 1 et 2 ont une signification spéciale et des utilisations conventionnelles et sont impliquées par certaines opérations de redirection; ils sont appelés respectivement entrée standard, sortie standard et erreur standard. Les programmes prennent généralement leur entrée de l'entrée standard et écrivent la sortie sur la sortie standard. Les messages d'erreur sont généralement écrits sur l'erreur standard. Les opérateurs de redirection peuvent être précédés d'un ou plusieurs chiffres (sans caractères intermédiaires autorisés) pour désigner le numéro de descripteur de fichier.


19

2 est l'erreur standard de la console.

1 est la sortie standard de la console.

Il s'agit de l'Unix standard et Windows suit également le POSIX.

Par exemple, lorsque vous courez

perl test.pl 2>&1

l'erreur standard est redirigée vers la sortie standard, vous pouvez donc voir les deux sorties ensemble:

perl test.pl > debug.log 2>&1

Après l'exécution, vous pouvez voir toutes les sorties, y compris les erreurs, dans le debug.log.

perl test.pl 1>out.log 2>err.log

Ensuite, la sortie standard passe à out.log et l'erreur standard à err.log.

Je vous suggère d'essayer de les comprendre.


Le deuxième exemple est faux: comme la priorité de commande STDERR est redirigée vers STDOUT , seul STDOUT par défaut sera écrit dans debug.log (pas STDERR ) voir ma réponse (le paragraphe # 2)! Pour vous assurer que les deux soient redirigés vers le même fichier, vous devez inverser les directives de redirection:perl test.pl > debug.log 2>&1
F. Hauri

16

Pour répondre à votre question: il prend n'importe quelle sortie d'erreur (normalement envoyée à stderr) et l'écrit sur la sortie standard (stdout).

Ceci est utile avec, par exemple, «plus» lorsque vous avez besoin de paginer pour toutes les sorties. Certains programmes comme l'impression des informations d'utilisation dans stderr.

Pour vous aider à vous souvenir

  • 1 = sortie standard (où les programmes impriment la sortie normale)
  • 2 = erreur standard (où les programmes impriment des erreurs)

"2> & 1" pointe simplement tout ce qui est envoyé vers stderr, vers stdout à la place.

Je recommande également de lire cet article sur la redirection d'erreur lorsque ce sujet est couvert en détail.


11

Du point de vue d'un programmeur, cela signifie précisément ceci:

dup2(1, 2);

Voir la page de manuel .

Comprendre qu'il 2>&1s'agit d'une copie explique également pourquoi ...

command >file 2>&1

... n'est pas la même chose que ...

command 2>&1 >file

Le premier enverra les deux flux vers file, tandis que le second enverra les erreurs stdoutet la sortie ordinaire vers file.


9

J'ai trouvé cela très utile si vous êtes un débutant, lisez ceci

Mise à jour:
sous Linux ou Unix, les programmes envoient deux sorties: sortie standard (stdout) et erreur standard (stderr). Vous pouvez rediriger ces sorties vers n'importe quel fichier.

Comme si vous faites ceci

ls -a > output.txt

Rien ne sera imprimé dans la console, toutes les sorties (stdout) sont redirigées vers le fichier de sortie.

Et si vous essayez d'imprimer le contenu d'un fichier qui ne se ferme pas, la sortie sera une erreur comme si vous imprimez test.txt qui n'est pas présent dans le répertoire courant La

cat test.txt > error.txt

sortie sera

cat: test.txt :No such file or directory

Mais le fichier error.txt sera vide car nous redirigeons la sortie standard vers un fichier non stderr.

nous avons donc besoin d'un descripteur de fichier (un descripteur de fichier n'est rien de plus qu'un entier positif qui représente un fichier ouvert. Vous pouvez dire que le descripteur est l'identifiant unique du fichier) pour indiquer au shell quel type de sortie nous envoyons au fichier .Dans le système Unix / Linux 1 est pour stdout et 2 pour stderr .

maintenant, si vous faites cela

ls -a 1> output.txt, cela signifie que vous envoyez une sortie standard (stdout) à output.txt.

et si vous le faites, cela

cat test.txt 2> error.txtsignifie que vous envoyez l'erreur standard (stderr) à error.txt.

&1est utilisé pour référencer la valeur du descripteur de fichier 1 (stdout).

Maintenant, au point 2>&1signifie "Rediriger le stderr au même endroit que nous redirigeons le stdout"

Vous pouvez maintenant le faire

cat maybefile.txt > output.txt 2>&1

la sortie standard (stdout) et l'erreur standard (stderr) seront redirigées vers output.txt.

Merci à Ondrej K. pour avoir souligné


1
Les réponses liées uniquement aux liens sont problématiques. Le lien peut devenir obsolète, rendant la réponse inutile. Vous devez toujours inclure suffisamment de détails dans la réponse elle-même.
Ondrej K.

7

Les gens, rappelez - vous toujours paxdiablo indice de sur le courant emplacement de la cible de redirection ... Il est important de .

Ma mnémonique personnelle pour l' 2>&1opérateur est la suivante:

  • Penser à & comme signifiant 'and'ou 'add'(le personnage est un esperluette - et , n'est-ce pas?)
  • Cela devient donc: "rediriger 2(stderr) vers 1(stdout) déjà / actuellement et ajouter les deux flux" .

Le même mnémonique fonctionne également pour les autres redirection fréquemment utilisées 1>&2:

  • Pensez au &sens andou add... (vous avez l'idée de l'esperluette, oui?)
  • Il devient donc: 'rediriger 1(stdout) vers où2 (stderr) déjà / actuellement et ajouter les deux flux» .

Et rappelez-vous toujours: vous devez lire les chaînes de redirections «de la fin», de droite à gauche ( pas de gauche à droite).


7

Rediriger l'entrée

La redirection de l'entrée entraîne l'ouverture du fichier dont le nom résulte de l'expansion du mot pour lecture sur le descripteur de fichier n, ou l'entrée standard (descripteur de fichier 0) si n n'est pas spécifié.

Le format général pour rediriger l'entrée est:

[n]<word

Redirection de la sortie

La redirection de la sortie entraîne l'ouverture du fichier dont le nom résulte de l'expansion du mot pour l'écriture sur le descripteur de fichier n, ou la sortie standard (descripteur de fichier 1) si n n'est pas spécifié. Si le fichier n'existe pas, il est créé; s'il existe, il est tronqué à zéro.

Le format général pour rediriger la sortie est:

[n]>word

Déplacer des descripteurs de fichiers

L'opérateur de redirection,

[n]<&digit-

déplace le chiffre du descripteur de fichier vers le descripteur de fichier n, ou l'entrée standard (descripteur de fichier 0) si n n'est pas spécifié. chiffre est fermé après avoir été dupliqué en n.

De même, l'opérateur de redirection

[n]>&digit-

déplace le chiffre du descripteur de fichier vers le descripteur de fichier n, ou la sortie standard (descripteur de fichier 1) si n n'est pas spécifié.

Réf:

man bash

Tapez /^REDIRECTpour accéder à la redirectionsection et en savoir plus ...

Une version en ligne est ici: 3.6 Redirection

PS:

Beaucoup de temps, manétait l'outil puissant pour apprendre Linux.


6

Pourvu que cela /foon'existe pas sur votre système et /tmpque ...

$ ls -l /tmp /foo

imprimera le contenu de /tmpet imprimera un message d'erreur pour/foo

$ ls -l /tmp /foo > /dev/null

enverra le contenu de /tmpà /dev/nullet imprimera un message d'erreur pour/foo

$ ls -l /tmp /foo 1> /dev/null

fera exactement la même chose (notez le 1 )

$ ls -l /tmp /foo 2> /dev/null

imprimera le contenu de /tmpet enverra le message d'erreur à/dev/null

$ ls -l /tmp /foo 1> /dev/null 2> /dev/null

enverra la liste ainsi que le message d'erreur à /dev/null

$ ls -l /tmp /foo > /dev/null 2> &1

est un raccourci


5

Cela revient à transmettre l'erreur à la sortie standard ou au terminal.

Autrement dit, cmdn'est pas une commande:

$cmd 2>filename
cat filename

command not found

L'erreur est envoyée au fichier comme ceci:

2>&1

L'erreur standard est envoyée au terminal.


1

0 pour entrée, 1 pour stdout et 2 pour stderr.

Un conseil : somecmd >1.txt 2>&1est correct, tout somecmd 2>&1 >1.txtest totalement faux sans aucun effet!


1

unix_commands 2>&1

Ceci est utilisé pour imprimer des erreurs sur le terminal.

Ce qui suit illustre le processus

  • Lorsque des erreurs sont produites, elles sont écrites dans le &2"tampon" d' adresse de mémoire d'erreur standard , à partir duquel le flux d'erreurs standard fait 2référence.
  • Lorsqu'une sortie est produite, elle est écrite dans l'adresse de mémoire de sortie standard &1"buffer", à partir de laquelle le flux de sortie standard fait 1référence.

Prenez donc le unix_commandsflux d'erreurs standard 2et redirigez >le flux (d'erreurs) vers l'adresse de mémoire de sortie standard &1, afin qu'ils soient diffusés sur le terminal et imprimés.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.