Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Chazelas
2004-09-09, 14:44(+02), Thomas:
si on ne veut pas voir ce qu'affiche une commande, on fait
commande>/dev/null
c'est bien ca ?
Oui. Enfin, ca veut dire que tout ce que "commande" ecrira sur son file descriptor 1 (sa sortie standard, une convention qui dit que c'est sur ce file descriptor qui est censé etre ouvert en ecriture que doivent etre envoyees les informations qu'a a afficher une application) sera envoyé dans un puis sans fond.
ca n'a aucune incidence sur le fonctionnement ?
En principe non.
Maintenant, certaines commandes vont vouloir verifier si la sortie standard est ou non un terminal pour basiquement faire des optimisations. C'est le cas en particulier de toutes les applications qui utilisent stdio.
Par exemple, la fonction printf fait partie de stdio.
Quand la sortie standard est un terminal, printf affiche son tampon des qu'il contient un saut de ligne. Dans le cas contraire, il ne l'affiche que quand il est plein (ou quand on fait un flush). C'est pour ca que parfois, quand on redirige une commande dans un fichier, l'affichage est parfois decalé.
D'un point de vue fonctionnel, quand la sortie est /dev/null, ca ne fait pas grande difference.
-- Stephane
2004-09-09, 14:44(+02), Thomas:
si on ne veut pas voir ce qu'affiche une commande,
on fait
commande>/dev/null
c'est bien ca ?
Oui. Enfin, ca veut dire que tout ce que "commande" ecrira sur
son file descriptor 1 (sa sortie standard, une convention qui
dit que c'est sur ce file descriptor qui est censé etre ouvert
en ecriture que doivent etre envoyees les informations qu'a a
afficher une application) sera envoyé dans un puis sans fond.
ca n'a aucune incidence sur le fonctionnement ?
En principe non.
Maintenant, certaines commandes vont vouloir verifier si
la sortie standard est ou non un terminal pour basiquement faire
des optimisations. C'est le cas en particulier de toutes les
applications qui utilisent stdio.
Par exemple, la fonction printf fait partie de stdio.
Quand la sortie standard est un terminal, printf affiche son
tampon des qu'il contient un saut de ligne. Dans le cas
contraire, il ne l'affiche que quand il est plein (ou quand on
fait un flush). C'est pour ca que parfois, quand on redirige une
commande dans un fichier, l'affichage est parfois decalé.
D'un point de vue fonctionnel, quand la sortie est /dev/null, ca
ne fait pas grande difference.
si on ne veut pas voir ce qu'affiche une commande, on fait
commande>/dev/null
c'est bien ca ?
Oui. Enfin, ca veut dire que tout ce que "commande" ecrira sur son file descriptor 1 (sa sortie standard, une convention qui dit que c'est sur ce file descriptor qui est censé etre ouvert en ecriture que doivent etre envoyees les informations qu'a a afficher une application) sera envoyé dans un puis sans fond.
ca n'a aucune incidence sur le fonctionnement ?
En principe non.
Maintenant, certaines commandes vont vouloir verifier si la sortie standard est ou non un terminal pour basiquement faire des optimisations. C'est le cas en particulier de toutes les applications qui utilisent stdio.
Par exemple, la fonction printf fait partie de stdio.
Quand la sortie standard est un terminal, printf affiche son tampon des qu'il contient un saut de ligne. Dans le cas contraire, il ne l'affiche que quand il est plein (ou quand on fait un flush). C'est pour ca que parfois, quand on redirige une commande dans un fichier, l'affichage est parfois decalé.
D'un point de vue fonctionnel, quand la sortie est /dev/null, ca ne fait pas grande difference.
-- Stephane
Thomas
In article (Dans l'article) , Stephane Chazelas wrote (écrivait) :
Oui.
En principe non.
merci pour toutes les explications :-))
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article)
<slrnck0ldp.22g.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> wrote (écrivait) :
Oui.
En principe non.
merci pour toutes les explications :-))
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) , Stephane Chazelas wrote (écrivait) :
Oui.
En principe non.
merci pour toutes les explications :-))
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
Stephane Chazelas
2004-09-09, 14:44(+02), Thomas:
si on ne veut pas voir ce qu'affiche une commande, on fait
commande>/dev/null
c'est bien ca ? ca n'a aucune incidence sur le fonctionnement ?
Note que c'est un raccourcis pour
commande 1> /dev/null
Par convention toujours, les commandes envoient leurs messages d'erreur (par opposition au messages de fonctionnement normal) sur un file descriptor different (2, standard error). Donc, si tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre le meme chemin que ceux pour standard output, ca evite d'avoir a ouvrir /dev/null une deuxieme fois et on economise un "file handle"). (a noter que le comportement de stdio est le meme quel que soit le type de fichier ouvert dessus: il n'y a pas de buffering pour stderr, il est important que les messages soient affiches le plut tot possible).
-- Stephane
2004-09-09, 14:44(+02), Thomas:
si on ne veut pas voir ce qu'affiche une commande,
on fait
commande>/dev/null
c'est bien ca ?
ca n'a aucune incidence sur le fonctionnement ?
Note que c'est un raccourcis pour
commande 1> /dev/null
Par convention toujours, les commandes envoient leurs messages
d'erreur (par opposition au messages de fonctionnement normal)
sur un file descriptor different (2, standard error). Donc, si
tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre
le meme chemin que ceux pour standard output, ca evite d'avoir a
ouvrir /dev/null une deuxieme fois et on economise un "file
handle"). (a noter que le comportement de stdio est le meme quel
que soit le type de fichier ouvert dessus: il n'y a pas de
buffering pour stderr, il est important que les messages soient
affiches le plut tot possible).
si on ne veut pas voir ce qu'affiche une commande, on fait
commande>/dev/null
c'est bien ca ? ca n'a aucune incidence sur le fonctionnement ?
Note que c'est un raccourcis pour
commande 1> /dev/null
Par convention toujours, les commandes envoient leurs messages d'erreur (par opposition au messages de fonctionnement normal) sur un file descriptor different (2, standard error). Donc, si tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre le meme chemin que ceux pour standard output, ca evite d'avoir a ouvrir /dev/null une deuxieme fois et on economise un "file handle"). (a noter que le comportement de stdio est le meme quel que soit le type de fichier ouvert dessus: il n'y a pas de buffering pour stderr, il est important que les messages soient affiches le plut tot possible).
-- Stephane
TiChou
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
Par convention toujours, les commandes envoient leurs messages d'erreur (par opposition au messages de fonctionnement normal) sur un file descriptor different (2, standard error). Donc, si tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre le meme chemin que ceux pour standard output, ca evite d'avoir a ouvrir /dev/null une deuxieme fois et on economise un "file handle").
Et on peut ajouter la syntaxe suivante qui fonctionne sous bash et zsh et qui aura le même effet que précédemment :
commande &> /dev/null
ou
commande >& /dev/null
-- TiChou
Dans le message <news:slrnck0p0c.22g.stephane.chazelas@spam.is.invalid>,
*Stephane Chazelas* tapota sur f.c.o.unix :
Par convention toujours, les commandes envoient leurs messages
d'erreur (par opposition au messages de fonctionnement normal)
sur un file descriptor different (2, standard error). Donc, si
tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre
le meme chemin que ceux pour standard output, ca evite d'avoir a
ouvrir /dev/null une deuxieme fois et on economise un "file
handle").
Et on peut ajouter la syntaxe suivante qui fonctionne sous bash et zsh et
qui aura le même effet que précédemment :
Dans le message <news:, *Stephane Chazelas* tapota sur f.c.o.unix :
Par convention toujours, les commandes envoient leurs messages d'erreur (par opposition au messages de fonctionnement normal) sur un file descriptor different (2, standard error). Donc, si tu veux aussi ignorer les messages d'erreur, tu fais:
commande 1> /dev/null 2> /dev/null
ou, mieux:
commande > /dev/null 2>&1
(2>&1 dit que les messages vers standard error doivent prendre le meme chemin que ceux pour standard output, ca evite d'avoir a ouvrir /dev/null une deuxieme fois et on economise un "file handle").
Et on peut ajouter la syntaxe suivante qui fonctionne sous bash et zsh et qui aura le même effet que précédemment :
