Il faut mettre le "2>&1" apres la redirection principale ? Pas intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé) Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty Après >/dev/null : 1 -> null, 2 -> tty Après 2>&1 : 1 -> null, 2 -> null
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et rien ne peut sortir.
Ici, pour le sous-shell, on a vu que 1 va vers /dev/null et 2 vers le tty.
JustMe wrote in message <mn.93ee7d67b66b7f57.51095@merci.beaucoup.con>:
Il faut mettre le "2>&1" apres la redirection principale ? Pas
intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre
où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty
Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé)
Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty
Après >/dev/null : 1 -> null, 2 -> tty
Après 2>&1 : 1 -> null, 2 -> null
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du
sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et
rien ne peut sortir.
Il faut mettre le "2>&1" apres la redirection principale ? Pas intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé) Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty Après >/dev/null : 1 -> null, 2 -> tty Après 2>&1 : 1 -> null, 2 -> null
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et rien ne peut sortir.
"d'instinct", je dirais que c'est interprété linéairement, et que si tu mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers /dev/null à ce moment là...
"d'instinct", je dirais que c'est interprété linéairement, et que si tu
mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers
/dev/null à ce moment là...
"d'instinct", je dirais que c'est interprété linéairement, et que si tu mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers /dev/null à ce moment là...
"d'instinct", je dirais que c'est interprété linéairement, et que si tu mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers /dev/null à ce moment là...
Ben oui, donc logiquement le > situé apres devrait s'appliquer aux deux. Or ca fait le contraire (cf. exemple)
"d'instinct", je dirais que c'est interprété linéairement, et que si tu
mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers
/dev/null à ce moment là...
Ben oui, donc logiquement le > situé apres devrait s'appliquer aux
deux. Or ca fait le contraire (cf. exemple)
"d'instinct", je dirais que c'est interprété linéairement, et que si tu mets 2>&1 en premier, la sortie standard n'est pas encore redirigé vers /dev/null à ce moment là...
Ben oui, donc logiquement le > situé apres devrait s'appliquer aux deux. Or ca fait le contraire (cf. exemple)
JustMe
Nicolas George a écrit
JustMe wrote in message :
Il faut mettre le "2>&1" apres la redirection principale ? Pas intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé)
pourquoi "rien de changé" ? Normalement 2>&1 fusionne stdout et stderr, non ?
Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty Après >/dev/null : 1 -> null, 2 -> tty Après 2>&1 : 1 -> null, 2 -> null
là je suis pas...
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et rien ne peut sortir.
Ici, pour le sous-shell, on a vu que 1 va vers /dev/null et 2 vers le tty.
Nicolas George a écrit
JustMe wrote in message <mn.93ee7d67b66b7f57.51095@merci.beaucoup.con>:
Il faut mettre le "2>&1" apres la redirection principale ? Pas
intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre
où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty
Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé)
pourquoi "rien de changé" ? Normalement 2>&1 fusionne stdout et stderr,
non ?
Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty
Après >/dev/null : 1 -> null, 2 -> tty
Après 2>&1 : 1 -> null, 2 -> null
là je suis pas...
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du
sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et
rien ne peut sortir.
Il faut mettre le "2>&1" apres la redirection principale ? Pas intuitif, mais effectivement ca marche...
Quelle est l'explication ?
Quand il n'y a pas de pipe en jeu, les redirections sont faites dans l'ordre où elles apparaissent. Donc :
foo 2>&1 >/dev/null
Avant redirection : 1 -> tty, 2 -> tty Après 2>&1 : 1 -> tty, 2 -> tty (rien de changé)
pourquoi "rien de changé" ? Normalement 2>&1 fusionne stdout et stderr, non ?
Après >/dev/null : 1 -> null, 2 -> tty
foo >/dev/null 2>&1
Avant redirection : 1 -> tty, 2 -> tty Après >/dev/null : 1 -> null, 2 -> tty Après 2>&1 : 1 -> null, 2 -> null
là je suis pas...
# (echo stderr >&2; echo stdout) > /dev/null 2>&1
Les redirections pour le sous-shell sont évidemment faites avant celles du sous-shell lui-même. Donc pour le sous-shell, 1 et 2 vont vers /dev/null, et rien ne peut sortir.
(sous Linux, une structure file n'a pas un pointeur directement vers un inode, mais un pointeur vers une dentry qui elle-même pointe vers l'inode, mais on s'en fout
Quand on fait une redirection du type 2>&1, ça fait en interne un dup2(1,2), ce qui veut dire : déconnecter le fd 2 de ce à quoi il était connecté, décrémenter le compteur de références en conséquence, libérer les ressources si nécessaire, puis connecter le fd 2 à la même chose que le fd 1, incrémenter le compteur de référence en conséquence.
Quand les fd 1 et 2 pointaient déjà sur la même chose, ça revient essentiellement à ne rien changer.
Bien sûr, après une telle redirection (et avant aussi, puisque ça n'a rien changé), tout ce qui travaille avec les structures file traitent les fd 1 et 2 comme exactement la même chose. Mais pas les appels système qui travaillent au niveau du file descriptor, ce qui est justement le cas des appels système mis en jeu par les redirections.
JustMe wrote in message <mn.94147d6713280e6d.51095@merci.beaucoup.con>:
pourquoi "rien de changé" ? Normalement 2>&1 fusionne stdout et stderr,
non ?
Non, il n'y a pas de notion de « fusionner » pour des file descriptors.
(sous Linux, une structure file n'a pas un pointeur directement vers un
inode, mais un pointeur vers une dentry qui elle-même pointe vers l'inode,
mais on s'en fout
Quand on fait une redirection du type 2>&1, ça fait en interne un dup2(1,2),
ce qui veut dire : déconnecter le fd 2 de ce à quoi il était connecté,
décrémenter le compteur de références en conséquence, libérer les ressources
si nécessaire, puis connecter le fd 2 à la même chose que le fd 1,
incrémenter le compteur de référence en conséquence.
Quand les fd 1 et 2 pointaient déjà sur la même chose, ça revient
essentiellement à ne rien changer.
Bien sûr, après une telle redirection (et avant aussi, puisque ça n'a rien
changé), tout ce qui travaille avec les structures file traitent les fd 1 et
2 comme exactement la même chose. Mais pas les appels système qui
travaillent au niveau du file descriptor, ce qui est justement le cas des
appels système mis en jeu par les redirections.
(sous Linux, une structure file n'a pas un pointeur directement vers un inode, mais un pointeur vers une dentry qui elle-même pointe vers l'inode, mais on s'en fout
Quand on fait une redirection du type 2>&1, ça fait en interne un dup2(1,2), ce qui veut dire : déconnecter le fd 2 de ce à quoi il était connecté, décrémenter le compteur de références en conséquence, libérer les ressources si nécessaire, puis connecter le fd 2 à la même chose que le fd 1, incrémenter le compteur de référence en conséquence.
Quand les fd 1 et 2 pointaient déjà sur la même chose, ça revient essentiellement à ne rien changer.
Bien sûr, après une telle redirection (et avant aussi, puisque ça n'a rien changé), tout ce qui travaille avec les structures file traitent les fd 1 et 2 comme exactement la même chose. Mais pas les appels système qui travaillent au niveau du file descriptor, ce qui est justement le cas des appels système mis en jeu par les redirections.
