Redirection de sortie partielle
Le
Francois Lafont
Bonjour à tous,
Je suis sous Debian Squeeze. Je butte sur un truc assez basique mais qui
m'intrigue et que je ne comprends pas. Voici ce que me donne la commande
ci-dessous :
--
# aptitude update -v
Atteint http://ftp2.fr.debian.org squeeze Release.gpg
Ign http://ftp2.fr.debian.org/debian/ squeeze/contrib Translation-en
Ign http://ftp2.fr.debian.org/debian/ squeeze/contrib Translation-fr
Atteint http://www.debian-multimedia.org squeeze Release.gpg
[Couic]
Atteint http://ftp2.fr.debian.org squeeze-updates/main amd64 Packages
État actuel : 0 paquet cassé [+0], 0 mise à jour restante [+0], 276
nouveaux paquets [+0].
#
--
Très bien, j'ai en sortie la dernière ligne que je voudrais isoler avec
un grep. Je tente alors ça :
--
# aptitude update -v | grep 'État actuel'
#
--
Aucune sortie. Je tente une redirection vers un fichier :
--
# aptitude update -v > out
--
Et dans le fichier out je retrouve toute la sortie que j'avais dans la
première commande, sauf la fameuse derrière ligne. Ok, là je me dis, sûr
de moi, c'est bon je sais ce qu'il se passe : la dernière ligne provient
du flux de sortie des erreurs standard (stderr) et non du flux de sortie
standard (stdout), alors je tente ça :
--
# aptitude update -v 2>&1 1> out
--
Et bien dans le fichier out, toujours pas cette fameuse dernière ligne.
Mais elle provient d'où alors cette dernière ligne si elle ne provient
ni de stdout et ni de stderr ? Comment faire pour la récupérer elle et
elle seule J'aimerais bien comprendre.
Merci d'avance pour votre aide.
--
François Lafont
Je suis sous Debian Squeeze. Je butte sur un truc assez basique mais qui
m'intrigue et que je ne comprends pas. Voici ce que me donne la commande
ci-dessous :
--
# aptitude update -v
Atteint http://ftp2.fr.debian.org squeeze Release.gpg
Ign http://ftp2.fr.debian.org/debian/ squeeze/contrib Translation-en
Ign http://ftp2.fr.debian.org/debian/ squeeze/contrib Translation-fr
Atteint http://www.debian-multimedia.org squeeze Release.gpg
[Couic]
Atteint http://ftp2.fr.debian.org squeeze-updates/main amd64 Packages
État actuel : 0 paquet cassé [+0], 0 mise à jour restante [+0], 276
nouveaux paquets [+0].
#
--
Très bien, j'ai en sortie la dernière ligne que je voudrais isoler avec
un grep. Je tente alors ça :
--
# aptitude update -v | grep 'État actuel'
#
--
Aucune sortie. Je tente une redirection vers un fichier :
--
# aptitude update -v > out
--
Et dans le fichier out je retrouve toute la sortie que j'avais dans la
première commande, sauf la fameuse derrière ligne. Ok, là je me dis, sûr
de moi, c'est bon je sais ce qu'il se passe : la dernière ligne provient
du flux de sortie des erreurs standard (stderr) et non du flux de sortie
standard (stdout), alors je tente ça :
--
# aptitude update -v 2>&1 1> out
--
Et bien dans le fichier out, toujours pas cette fameuse dernière ligne.
Mais elle provient d'où alors cette dernière ligne si elle ne provient
ni de stdout et ni de stderr ? Comment faire pour la récupérer elle et
elle seule J'aimerais bien comprendre.
Merci d'avance pour votre aide.
--
François Lafont

Poser une question


le 16/01/2012 à 18:49, Francois Lafont a écrit dans le message
Là tu rediriges stderr à l'endroit où se trouve stdout (le terminal dans
lequel tu es) puis tu rediriges stdout (pas ce que tu as redirigé
auparavant) dans le fichier out.
atitude update -v >out 2>&1
Là ça redirige stdout dans le fichier out puis stderr dans stdout (le
fichier out).
--
Benoit Izac
source de confusion possible. (Je ne pense pas que ce soit ça, mais ça ne
mange pas de pain.)
2) si c'est pas stderr vs stdout, ça pourrait etre une histoire de
buffering, sauf que ton aptitude a l'air de se terminer avant que tu
regardes le contenu du fichier.
3) aptitude pourrait regarder si son stdout pointe sur un terminal et
afficher plus de messages dans ce cas. (Ça fait chier les programmes qui
veulent etre trop intelligents.)
Alors, j'ai bien fait de poser la question car j'ai appris quelque
chose. Donc, si je suis bien ce que tu me dis, l'ordre dans lequel on
précise les redirection compte, c'est ça ? ceci :
# commande 2>&1 1> out
serait finalement équivalent à cela :
# commande 1> out
C'est bien ça ?
Ok. Et bien soit. Mais même de cette manière j'ai toujours le même
problème : je ne retrouve pas la fameuse ligne dans le fichier out.
--
François Lafont
le 16/01/2012 à 19:12, Francois Lafont a écrit dans le message
Oui puisque par défaut stderr est redirigé vers stdout.
% cat abcd >/dev/null
cat: abcd: No such file or directory
% cat abcd >/dev/null 2>&1
% cat abcd 2>&1 >/dev/null
cat: abcd: No such file or directory
Je passe.
--
Benoit Izac
:
Oui le problème ne vient pas de là, mais merci pour le coup du :
LC_ALL=C aptitude update -v
car effectivement les accents sont une source d'embrouilles alors ce
truc là, je vais le retenir.
Si je comprends bien la variable d'environnement LC_ALL défnie la
langue, mais à quoi correspond la valeur « C » ?
Pas sûr d'avoir compris ce que tu veux dire. J'ouvre mon fichier out une
fois la commande terminée. Ça serait possible que « ça » continue à
écrire dans le fichier alors que la commande est terminée et que j'ai le
prompt ? Si oui, à quoi correspondrait « ça » ?
Ah peut-être, j'ai un peu pensé à un truc dans le genre. Et comment en
shell bash par exemple on fait pour savoir si stdout pointe sur un
terminal ou non ? Je serais curieux de le savoir. Y a-t-il une variable
d'environnement à tester ? Auquel cas on pourrait peut-être leurrer la
commande.
--
François Lafont