J'aimerais savoir comment éviter les messages d'erreur "Broken pipe"
d'utilitaires que je n'ai pas écrits (et que je ne peux/veux pas
modifier). Par exemple:
svn log | head
donne un message d'erreur:
svn: Write error: Broken pipe
Ce genre de message d'erreur est particulièrement ennuyeux dans le
cas suivant:
script | head
où script exécute le "svn log" et récupère le résultat par pipe.
Dans ce cas, j'obtiens le message d'erreur après l'affichage du
prompt.
À noter que "cat" n'a pas ce problème: il est simplement tué par le
signal SIGPIPE, donc pas de message sur stderr et l'utilisateur peut
utiliser l'exit status pour connaître la cause du problème, e.g. sous
zsh:
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
2008-04-17, 22:21(+00), Vincent Lefevre: [...]
J'aimerais savoir comment éviter les messages d'erreur "Broken pipe" d'utilitaires que je n'ai pas écrits (et que je ne peux/veux pas modifier). Par exemple:
svn log | head
donne un message d'erreur:
svn: Write error: Broken pipe [...]
Evite le SIGPIPE:
svn log | sed '1,10!d'
-- Stéphane
2008-04-17, 22:21(+00), Vincent Lefevre:
[...]
J'aimerais savoir comment éviter les messages d'erreur "Broken pipe"
d'utilitaires que je n'ai pas écrits (et que je ne peux/veux pas
modifier). Par exemple:
J'aimerais savoir comment éviter les messages d'erreur "Broken pipe" d'utilitaires que je n'ai pas écrits (et que je ne peux/veux pas modifier). Par exemple:
svn log | head
donne un message d'erreur:
svn: Write error: Broken pipe [...]
Evite le SIGPIPE:
svn log | sed '1,10!d'
-- Stéphane
Vincent Lefevre
Dans l'article , Stephane Chazelas écrit:
Evite le SIGPIPE:
svn log | sed '1,10!d'
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Note: je préfère éviter l'utilisation de l'option --limit de "svn log", qui se base sur le nombre d'entrées et non sur le nombre de lignes.
Dans l'article <slrng0gjkg.4ri.stephane.chazelas@spam.is.invalid>,
Stephane Chazelas <cette.adresse@est.invalid> écrit:
Evite le SIGPIPE:
svn log | sed '1,10!d'
Cette solution ne me convient pas pour des raisons d'efficacité:
le "svn log" complet peut prendre énormément de temps (plusieurs
dizaines de secondes, voire plusieurs minutes), alors que je n'ai
besoin que des premières lignes.
Note: je préfère éviter l'utilisation de l'option --limit de
"svn log", qui se base sur le nombre d'entrées et non sur le
nombre de lignes.
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Note: je préfère éviter l'utilisation de l'option --limit de "svn log", qui se base sur le nombre d'entrées et non sur le nombre de lignes.
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ? -- Jacques L'helgoualc'h
Cette solution ne me convient pas pour des raisons d'efficacité:
le "svn log" complet peut prendre énormément de temps (plusieurs
dizaines de secondes, voire plusieurs minutes), alors que je n'ai
besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
--
Jacques L'helgoualc'h
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ? -- Jacques L'helgoualc'h
Matthieu Moy
Jacques L'helgoualc'h <lhh+ writes:
Le 18-04-2008, Vincent Lefevre a écrit :
Stephane Chazelas écrit:
Evite le SIGPIPE:
svn log | sed '1,10!d'
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ». Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
-- Matthieu
Jacques L'helgoualc'h <lhh+no_spam@free.fr> writes:
Cette solution ne me convient pas pour des raisons d'efficacité:
le "svn log" complet peut prendre énormément de temps (plusieurs
dizaines de secondes, voire plusieurs minutes), alors que je n'ai
besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ».
Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ». Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ». Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Cette solution ne me convient pas pour des raisons d'efficacité:
le "svn log" complet peut prendre énormément de temps (plusieurs
dizaines de secondes, voire plusieurs minutes), alors que je n'ai
besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ».
Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Cette solution ne me convient pas pour des raisons d'efficacité: le "svn log" complet peut prendre énormément de temps (plusieurs dizaines de secondes, voire plusieurs minutes), alors que je n'ai besoin que des premières lignes.
Est-ce que « sed 10q » convient mieux ?
On en revient au problème initial : svn rale sur un « broken pipe ». Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Vincent Lefevre
Dans l'article , Matthieu Moy écrit:
On en revient au problème initial : svn rale sur un « broken pipe ». Je ne crois pas qu'il y ait de solution autre que de patcher svn ...
Je viens de voir qu'un bug a finalement été rapporté:
D'ailleurs, comme indiqué dans le rapport de bug, le problème avait déjà été mentionné plusieurs fois dans la liste de développement (dont par moi-même).
D'ailleurs, comme indiqué dans le rapport de bug, le problème avait
déjà été mentionné plusieurs fois dans la liste de développement
(dont par moi-même).
D'ailleurs, comme indiqué dans le rapport de bug, le problème avait déjà été mentionné plusieurs fois dans la liste de développement (dont par moi-même).
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
Je ne veux pas ignorer les autres messages d'erreur éventuels.
Une solution serait peut-être d'écrire un wrapper pour récupérer la sortie d'erreur de svn et filtrer le message indiquant un broken pipe uniquement, avec les inconvénients que cela pose: problèmes éventuels de bufferisation ou de "désynchronisation" entre stdout et stderr, et prise en compte des traductions.
En fait, dans mon cas, j'ai déjà un wrapper qui reformate la sortie de "svn log" (cf mon premier message), mais ça le complique encore plus, car cette fois, il faut également que je trappe SIGPIPE dans mon wrapper. D'ailleurs, pour éviter le message d'erreur de svn après le prompt, il vaut mieux que je le fasse, afin d'être sûr que mon wrapper termine après svn.
Dans l'article <wt9tzhzquey.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit:
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
Je ne veux pas ignorer les autres messages d'erreur éventuels.
Une solution serait peut-être d'écrire un wrapper pour récupérer
la sortie d'erreur de svn et filtrer le message indiquant un
broken pipe uniquement, avec les inconvénients que cela pose:
problèmes éventuels de bufferisation ou de "désynchronisation"
entre stdout et stderr, et prise en compte des traductions.
En fait, dans mon cas, j'ai déjà un wrapper qui reformate la sortie
de "svn log" (cf mon premier message), mais ça le complique encore
plus, car cette fois, il faut également que je trappe SIGPIPE dans
mon wrapper. D'ailleurs, pour éviter le message d'erreur de svn
après le prompt, il vaut mieux que je le fasse, afin d'être sûr que
mon wrapper termine après svn.
Et en redirigeant la sortie d'erreur de svn vers /dev/null ?
Je ne veux pas ignorer les autres messages d'erreur éventuels.
Une solution serait peut-être d'écrire un wrapper pour récupérer la sortie d'erreur de svn et filtrer le message indiquant un broken pipe uniquement, avec les inconvénients que cela pose: problèmes éventuels de bufferisation ou de "désynchronisation" entre stdout et stderr, et prise en compte des traductions.
En fait, dans mon cas, j'ai déjà un wrapper qui reformate la sortie de "svn log" (cf mon premier message), mais ça le complique encore plus, car cette fois, il faut également que je trappe SIGPIPE dans mon wrapper. D'ailleurs, pour éviter le message d'erreur de svn après le prompt, il vaut mieux que je le fasse, afin d'être sûr que mon wrapper termine après svn.
