web-dev-qa-db-fra.com

gnome-terminal commence par le message "grep: write error: Broken pipe"

Je suis sous Ubuntu 14.04.3, il est à jour. Je ne sais pas pourquoi, pendant quelques jours, j'ai commencé à prendre le message grep: write error: Broken pipe au lancement de gnome-terminal . Cela semble être inoffensif mais cela me dérange. Comment puis-je le déboguer?

EDIT: j'ai déplacé des alias et des fonctions chacun pour séparer des fichiers tels que .bash_aliases et .bash_functions et ajouté une commande pour les charger à partir de .bashrc

 if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
 fi

 if [ -f ~/.bash_functions ]; then
. ~/.bash_functions
 fi

Si je ne charge pas .bash_functions, le problème disparaît.

J'essaie de trouver le défectueux en désactivant chaque fonction une par une.

Celui-ci me donne la même erreur, mais lorsque je la désactive, je reçois toujours la même erreur, de sorte que d'autres fonctions peuvent être défaillantes.

 ls -lt  $PWD| grep ^d | head -1 | cut -b 51- 

 grep:  development
 write error: Broken pipe

Je me demande pourquoi je commence à prendre cette erreur.

EDIT2:

J'ai trouvé un problème similaire ici boken pipe

La racine du problème semble également similaire.

J'ai essayé la commande de test donnée dans le lien qui ont la même erreur:

 bash -c '(while echo foo; do :; done); echo status=$? >&2' |  head
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 bash: line 0: echo: write error: Broken pipe
 status=0

EDIT3:

Bien que cette solution de contournement unbuffer que j'ai postée ci-dessous comme réponse à ma propre question fonctionne, je n'en suis pas satisfaite, mais mes connaissances en débogage sont limitées. Selon ce lien https://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00080.html il découle du piège SIGPIPE par une autre tâche, et ce lien - https://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00154.html identifie la cause exacte du problème, il s'agit de l'un des modules d'authentification de pam avec lesquels je suis en difficulté avec cela récemment.

bashgnome-terminalbashrc
3
kenn

Après des heures de lutte avec le problème, j'ai trouvé une solution de contournement (je l'espère)

Le problème semble être plus profond et compliqué. Beaucoup de gens ont rencontré le même bug. La réparer est au-delà de ma couverture.

Solution de contournement la plus proche publiée ici comment-puis-je-réparer-une-erreur-de-pipe-cassée par Andrew Beals en bas comme:

ls -lt $PWD|dd obs=1M | grep -m 1 ^d | cut -b 51-

n'est pas chouette.

Quand j'ai eu l'intuition qu'il était lié au tampon de pipe, j'ai donné l'exemple à la commande unbuffer comme:

 unbuffer ls -lt $PWD| grep -m 1 ^d | cut -b 51-

Ça marche bien.

J'espère que quelqu'un affiche la vraie cause du problème.

EDIT: Un gourou bash suggérerait cette solution simple, en redirigeant stderr vers /dev/null

 ls -lt $PWD 2>/dev/null | grep -m 1 ^d | cut -b 51-
3
kenn

Il y a une bonne explication de ce problème sur cette réponse du super utilisateur: Comment puis-je réparer une erreur Broken Pipe? .

Les commandes dans les tubes sont exécutées de manière asynchrone: cela signifie que dans un tube tel que command1 | command2, rien ne garantit que command1 se terminera avant command2.

Lorsque vous utilisez [...] | grep | head -n 1, headse termine dès qu’il a lu une ligne; si cela se produit avant que grepait fini d'écrire dans le canal, grepreçoit un signal SIGPIPE et sort en erreur.

Comme expliqué dans la réponse ci-dessous, la réponse du super utilisateur est une solution de contournement consistant à rediriger en priorité la sortie de ce qui se trouvait avant headdu pipeline vers tail -n +1, ce qui ignorera le signal SIGPIPE:

command | tail -n +1 | head -n 1

Mais dans ce cas, il n’a même pas besoin de headname__, puisque grepa une option permettant d’imprimer uniquement la première correspondance:

[...] | grep -m 1
2
kos