je fais
1)rmdir aa > /dev/null 2>&1
et rien ne s'affiche à l'écran
j'essaie de comprendre :
D'abord l'instruction rmdir aa >/dev/ null semble envoyer la sortie ecran à
la corbeille mais n'en fait pas de même pour la sortie erreur qui s'affiche
à l'écran.
Or 2>&1 redirige 2 vers l'écran, aussi je ne comprends pas que rien
s'affiche à la fin de 1)
ensuite je fais
2)rmdir aa 2>&1 > /dev/null
et s'affiche alors " rmdir : aa :Aucun fichier ou répertoire de ce type."
J'essaie de comprendre :
rmdir aa 2>&1 redirige 2 vers 1 donc le message d'erreur vers la sortie
écran
et > /dev/null envoie cette sortie à la corbeille. Aussi je ne comprends
pas que dans ce cas un message d'erreur apparaisse.
Je me doute que cette question est bien connue et malgré mes recherches avec
google et les livres
Linux Redhat Fedora (700 pages) je n'arrive pas à éclaircir ce mystère.
Merci mille fois à celui qui saura m'expliquer ces redirections qui me
paraissent obscures.
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
Un file descriptor pointe vers un élément « description », qui correspond plus directement au fichier ou pseudo-fichier (extrémité de pipe, device) lui-même.
Plusieurs file descriptors peuvent pointer sur la même description. Le noyau garde le compte, pour chaque description, du nombre de file descriptors qui pointent dessus. Quand ce nombre tombe a zéro, il supprime la description.
L'appel système open crée une description pour le fichier indiqué, puis trouve le premier file descriptor libre, et le fait pointer sur cette description.
L'appel système close(X) vide le file descriptor X. Ce qui peut avoir pour conséquence de supprimer la description correspondante.
L'appel système dup2(X, Y) commence par faire comme close(Y), puis copie le file descriptor X dans le file descriptor Y.
Quand on écrit « X> foo », le shell commence par faire un open("foo"), et obtient un filedescriptor Y qui pointe vers une description correspondant au fichier foo. Ensuite, si X est différent de Y, le shell fait un dup2(Y, X), de sorte que maintenant, le file descriptor X pointe vers la description de foo. Enfin, il appelle close(Y).
Quand on écrit « X>&Y », le shell fait un dup2(Y, X).
Dernier point : quand on a « foo | bar », le shell appelle pipe pour obtenir une paire de file descriptors X et Y qui correspondent à une paire de descriptions qui sont les extrémités d'un pipe. Puis il se scinde en deux processus. Dans celui de gauche, il ferme le file descriptor X de lecture, puis se débrouille avec fup2 et close pour que le file descriptor Y d'écriture devienne 1. Idem dans le processus de droite, il ne garde que le file descriptor X de lecture et se débrouille pour qu'il devienne 0. Ceci se produit _avant_ de commencer à faire les redirections décrites dans foo. Donc quand on a un pipe, la redirection correspondant au pipe, bien qu'apparaissant tout à droite de la commande de gauche, intervient en premier.
"vraifaux" wrote in message <h8e519$h7k$1@shakotay.alphanet.ch>:
on duplique le fd 1 et on l'assigne au fd 2 ?
Un programme Unix manipule les fichiers par le biais de file descriptors
(fd), de petits entiers qui servent au noyau d'index pour des structures de
données.
Un file descriptor pointe vers un élément « description », qui correspond
plus directement au fichier ou pseudo-fichier (extrémité de pipe, device)
lui-même.
Plusieurs file descriptors peuvent pointer sur la même description. Le noyau
garde le compte, pour chaque description, du nombre de file descriptors qui
pointent dessus. Quand ce nombre tombe a zéro, il supprime la description.
L'appel système open crée une description pour le fichier indiqué, puis
trouve le premier file descriptor libre, et le fait pointer sur cette
description.
L'appel système close(X) vide le file descriptor X. Ce qui peut avoir pour
conséquence de supprimer la description correspondante.
L'appel système dup2(X, Y) commence par faire comme close(Y), puis copie le
file descriptor X dans le file descriptor Y.
Quand on écrit « X> foo », le shell commence par faire un open("foo"), et
obtient un filedescriptor Y qui pointe vers une description correspondant au
fichier foo. Ensuite, si X est différent de Y, le shell fait un dup2(Y, X),
de sorte que maintenant, le file descriptor X pointe vers la description de
foo. Enfin, il appelle close(Y).
Quand on écrit « X>&Y », le shell fait un dup2(Y, X).
Dernier point : quand on a « foo | bar », le shell appelle pipe pour obtenir
une paire de file descriptors X et Y qui correspondent à une paire de
descriptions qui sont les extrémités d'un pipe. Puis il se scinde en deux
processus. Dans celui de gauche, il ferme le file descriptor X de lecture,
puis se débrouille avec fup2 et close pour que le file descriptor Y
d'écriture devienne 1. Idem dans le processus de droite, il ne garde que le
file descriptor X de lecture et se débrouille pour qu'il devienne 0. Ceci se
produit _avant_ de commencer à faire les redirections décrites dans foo.
Donc quand on a un pipe, la redirection correspondant au pipe, bien
qu'apparaissant tout à droite de la commande de gauche, intervient en
premier.
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
Un file descriptor pointe vers un élément « description », qui correspond plus directement au fichier ou pseudo-fichier (extrémité de pipe, device) lui-même.
Plusieurs file descriptors peuvent pointer sur la même description. Le noyau garde le compte, pour chaque description, du nombre de file descriptors qui pointent dessus. Quand ce nombre tombe a zéro, il supprime la description.
L'appel système open crée une description pour le fichier indiqué, puis trouve le premier file descriptor libre, et le fait pointer sur cette description.
L'appel système close(X) vide le file descriptor X. Ce qui peut avoir pour conséquence de supprimer la description correspondante.
L'appel système dup2(X, Y) commence par faire comme close(Y), puis copie le file descriptor X dans le file descriptor Y.
Quand on écrit « X> foo », le shell commence par faire un open("foo"), et obtient un filedescriptor Y qui pointe vers une description correspondant au fichier foo. Ensuite, si X est différent de Y, le shell fait un dup2(Y, X), de sorte que maintenant, le file descriptor X pointe vers la description de foo. Enfin, il appelle close(Y).
Quand on écrit « X>&Y », le shell fait un dup2(Y, X).
Dernier point : quand on a « foo | bar », le shell appelle pipe pour obtenir une paire de file descriptors X et Y qui correspondent à une paire de descriptions qui sont les extrémités d'un pipe. Puis il se scinde en deux processus. Dans celui de gauche, il ferme le file descriptor X de lecture, puis se débrouille avec fup2 et close pour que le file descriptor Y d'écriture devienne 1. Idem dans le processus de droite, il ne garde que le file descriptor X de lecture et se débrouille pour qu'il devienne 0. Ceci se produit _avant_ de commencer à faire les redirections décrites dans foo. Donc quand on a un pipe, la redirection correspondant au pipe, bien qu'apparaissant tout à droite de la commande de gauche, intervient en premier.
Eric Dorino
On Fri, 11 Sep 2009 20:31:12 +0200, vraifaux wrote:
Qu'entendez vous par on duplique le fd 1 et on l'assigne au fd 2 ?
Tiens, je n'ai rien de mieux que le message de Nicolas.
-- Eric
On Fri, 11 Sep 2009 20:31:12 +0200, vraifaux wrote:
Qu'entendez vous par
on duplique le fd 1 et on l'assigne au fd 2 ?
Tiens, je n'ai rien de mieux que le message de Nicolas.
On Fri, 11 Sep 2009 20:31:12 +0200, vraifaux wrote:
Qu'entendez vous par on duplique le fd 1 et on l'assigne au fd 2 ?
Tiens, je n'ai rien de mieux que le message de Nicolas.
-- Eric
vraifaux
"vraifaux" a écrit dans le message de news: h8cqiu$l0b$
Bonjour,
J'ai un répertoire /travail qui est vide.
je fais 1)rmdir aa > /dev/null 2>&1 et rien ne s'affiche à l'écran
j'essaie de comprendre : D'abord l'instruction rmdir aa >/dev/ null semble envoyer la sortie ecran à la corbeille mais n'en fait pas de même pour la sortie erreur qui s'affiche à l'écran.
Or 2>&1 redirige 2 vers l'écran, aussi je ne comprends pas que rien s'affiche à la fin de 1)
ensuite je fais 2)rmdir aa 2>&1 > /dev/null et s'affiche alors " rmdir : aa :Aucun fichier ou répertoire de ce type."
J'essaie de comprendre : rmdir aa 2>&1 redirige 2 vers 1 donc le message d'erreur vers la sortie écran et > /dev/null envoie cette sortie à la corbeille. Aussi je ne comprends pas que dans ce cas un message d'erreur apparaisse.
Merci à tous et notamment à Eric Dorino dont l'explication
"La situation de départ: stdout (fd 1) sur /dev/pts/42 stderr (fd 2) sur /dev/pts/42
En spécifiant ls 2>&1 >/dev/null: - on duplique le fd 1 et on l'assigne au fd 2 (ce qui ne change rien); - on assigne /dev/null sur stdout; stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/pts/42 et les erreurs vont sur le terminal.
En spécifiant ls >/dev/null 2>&1: - on assigne /dev/null sur stdout. stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/pts/42 - on duplique le fd 1 et on l'assigne au fd 2; stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/null et le programme est muet."
est claire et à Nicolas George dont l'explication complète méritera encore plusieurs lectures.
"vraifaux" <w@wanadoo.fr> a écrit dans le message de news:
h8cqiu$l0b$1@shakotay.alphanet.ch...
Bonjour,
J'ai un répertoire /travail qui est vide.
je fais
1)rmdir aa > /dev/null 2>&1
et rien ne s'affiche à l'écran
j'essaie de comprendre :
D'abord l'instruction rmdir aa >/dev/ null semble envoyer la sortie ecran
à la corbeille mais n'en fait pas de même pour la sortie erreur qui
s'affiche à l'écran.
Or 2>&1 redirige 2 vers l'écran, aussi je ne comprends pas que rien
s'affiche à la fin de 1)
ensuite je fais
2)rmdir aa 2>&1 > /dev/null
et s'affiche alors " rmdir : aa :Aucun fichier ou répertoire de ce type."
J'essaie de comprendre :
rmdir aa 2>&1 redirige 2 vers 1 donc le message d'erreur vers la sortie
écran
et > /dev/null envoie cette sortie à la corbeille. Aussi je ne comprends
pas que dans ce cas un message d'erreur apparaisse.
Merci à tous et notamment à Eric Dorino dont l'explication
"La situation de départ:
stdout (fd 1) sur /dev/pts/42
stderr (fd 2) sur /dev/pts/42
En spécifiant ls 2>&1 >/dev/null:
- on duplique le fd 1 et on l'assigne au fd 2 (ce qui ne change rien);
- on assigne /dev/null sur stdout;
stdout (fd 1) sur /dev/null
stderr (fd 2) sur /dev/pts/42
et les erreurs vont sur le terminal.
En spécifiant ls >/dev/null 2>&1:
- on assigne /dev/null sur stdout.
stdout (fd 1) sur /dev/null
stderr (fd 2) sur /dev/pts/42
- on duplique le fd 1 et on l'assigne au fd 2;
stdout (fd 1) sur /dev/null
stderr (fd 2) sur /dev/null
et le programme est muet."
est claire
et à Nicolas George dont l'explication complète méritera encore plusieurs
lectures.
"vraifaux" a écrit dans le message de news: h8cqiu$l0b$
Bonjour,
J'ai un répertoire /travail qui est vide.
je fais 1)rmdir aa > /dev/null 2>&1 et rien ne s'affiche à l'écran
j'essaie de comprendre : D'abord l'instruction rmdir aa >/dev/ null semble envoyer la sortie ecran à la corbeille mais n'en fait pas de même pour la sortie erreur qui s'affiche à l'écran.
Or 2>&1 redirige 2 vers l'écran, aussi je ne comprends pas que rien s'affiche à la fin de 1)
ensuite je fais 2)rmdir aa 2>&1 > /dev/null et s'affiche alors " rmdir : aa :Aucun fichier ou répertoire de ce type."
J'essaie de comprendre : rmdir aa 2>&1 redirige 2 vers 1 donc le message d'erreur vers la sortie écran et > /dev/null envoie cette sortie à la corbeille. Aussi je ne comprends pas que dans ce cas un message d'erreur apparaisse.
Merci à tous et notamment à Eric Dorino dont l'explication
"La situation de départ: stdout (fd 1) sur /dev/pts/42 stderr (fd 2) sur /dev/pts/42
En spécifiant ls 2>&1 >/dev/null: - on duplique le fd 1 et on l'assigne au fd 2 (ce qui ne change rien); - on assigne /dev/null sur stdout; stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/pts/42 et les erreurs vont sur le terminal.
En spécifiant ls >/dev/null 2>&1: - on assigne /dev/null sur stdout. stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/pts/42 - on duplique le fd 1 et on l'assigne au fd 2; stdout (fd 1) sur /dev/null stderr (fd 2) sur /dev/null et le programme est muet."
est claire et à Nicolas George dont l'explication complète méritera encore plusieurs lectures.
Nicolas George
Nicolas George wrote in message <4aaaa1d1$0$31100$:
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la différence entre ces deux commandes :
programme >log 2>&1 programme >log 2>>log
Tous les éléments de réponses ne sont pas dans mon message, mais il y a l'essentiel.
Nicolas George wrote in message
<4aaaa1d1$0$31100$426a74cc@news.free.fr>:
Un programme Unix manipule les fichiers par le biais de file descriptors
(fd), de petits entiers qui servent au noyau d'index pour des structures de
données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la
différence entre ces deux commandes :
programme >log 2>&1
programme >log 2>>log
Tous les éléments de réponses ne sont pas dans mon message, mais il y a
l'essentiel.
Nicolas George wrote in message <4aaaa1d1$0$31100$:
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la différence entre ces deux commandes :
programme >log 2>&1 programme >log 2>>log
Tous les éléments de réponses ne sont pas dans mon message, mais il y a l'essentiel.
vraifaux
"Nicolas George" <nicolas$ a écrit dans le message de news: 4aab4ea9$0$22872$
Nicolas George wrote in message <4aaaa1d1$0$31100$:
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la différence entre ces deux commandes :
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing tv.mpg.
?
Exiting... (End of fichier)
mplayer tv.mpg >log 2>&1 affiche comme mplayer tv.mpg
Il reste une enigme :
l'erreur dans 2) et 3)
Can't open joystick device /dev/input/js0: No such file or directory
est raccourcie dans 1) en
o such file or directory.
Pourquoi?
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: 4aab4ea9$0$22872$426a74cc@news.free.fr...
Nicolas George wrote in message
<4aaaa1d1$0$31100$426a74cc@news.free.fr>:
Un programme Unix manipule les fichiers par le biais de file descriptors
(fd), de petits entiers qui servent au noyau d'index pour des structures
de
données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la
différence entre ces deux commandes :
"Nicolas George" <nicolas$ a écrit dans le message de news: 4aab4ea9$0$22872$
Nicolas George wrote in message <4aaaa1d1$0$31100$:
Un programme Unix manipule les fichiers par le biais de file descriptors (fd), de petits entiers qui servent au noyau d'index pour des structures de données.
<snip>
Exercices pour ceux qui pensent avoir compris : comprendre et expliquer la différence entre ces deux commandes :
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing tv.mpg.
?
Exiting... (End of fichier)
mplayer tv.mpg >log 2>&1 affiche comme mplayer tv.mpg
Il reste une enigme :
l'erreur dans 2) et 3)
Can't open joystick device /dev/input/js0: No such file or directory
est raccourcie dans 1) en
o such file or directory.
Pourquoi?
YBM
vraifaux a écrit :
"Nicolas George" <nicolas$ a écrit dans le message de
...
programme >log 2>&1 programme >log 2>>log
J'ai experimenté .
1)[ /]# mplayer tv.mpg >log1 2>>log1
On peut choisir une commande plus simple... $ ls -d /var /rav ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type /var
...
Can't open joystick device /dev/input/js0: No such file or directory
est raccourcie dans 1) en
o such file or directory.
Pourquoi?
$ rm -f log; ls -d /var /rav >log 2>&1 ; cat log ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type /var
$ rm -f log; ls -d /var /rav >log 2>>log ; cat log /var e peut accéder /rav: Aucun fichier ou répertoire de ce type
idem.
Combien de fois le fichier est-il ouvert dans les deux cas de figure ?
Outre qu'ouvrir en écriture deux fois le fichier est source d'ennuis assurés (comme ici), c'est, amha, le buffer d'e/s de la libc qui emmelle encore plus les données.
vraifaux a écrit :
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
On peut choisir une commande plus simple...
$ ls -d /var /rav
ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type
/var
...
Can't open joystick device /dev/input/js0: No such file or directory
est raccourcie dans 1) en
o such file or directory.
Pourquoi?
$ rm -f log; ls -d /var /rav >log 2>&1 ; cat log
ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type
/var
$ rm -f log; ls -d /var /rav >log 2>>log ; cat log
/var
e peut accéder /rav: Aucun fichier ou répertoire de ce type
idem.
Combien de fois le fichier est-il ouvert dans les deux cas de
figure ?
Outre qu'ouvrir en écriture deux fois le fichier est source
d'ennuis assurés (comme ici), c'est, amha, le buffer d'e/s
de la libc qui emmelle encore plus les données.
"Nicolas George" <nicolas$ a écrit dans le message de
...
programme >log 2>&1 programme >log 2>>log
J'ai experimenté .
1)[ /]# mplayer tv.mpg >log1 2>>log1
On peut choisir une commande plus simple... $ ls -d /var /rav ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type /var
...
Can't open joystick device /dev/input/js0: No such file or directory
est raccourcie dans 1) en
o such file or directory.
Pourquoi?
$ rm -f log; ls -d /var /rav >log 2>&1 ; cat log ls: ne peut accéder /rav: Aucun fichier ou répertoire de ce type /var
$ rm -f log; ls -d /var /rav >log 2>>log ; cat log /var e peut accéder /rav: Aucun fichier ou répertoire de ce type
idem.
Combien de fois le fichier est-il ouvert dans les deux cas de figure ?
Outre qu'ouvrir en écriture deux fois le fichier est source d'ennuis assurés (comme ici), c'est, amha, le buffer d'e/s de la libc qui emmelle encore plus les données.
