91 votes

Comment rendre la sortie de n'importe quelle commande shell non bufferisée ?

Existe-t-il un moyen d'exécuter des commandes shell sans tampon de sortie ?

Par exemple, hexdump file | ./my_script ne transmettra l'entrée de hexdump à my_script que par morceaux tamponnés, pas ligne par ligne.

En fait, j'aimerais connaître une solution générale pour rendre n'importe quelle commande non tamponnée.

2 votes

Plus de questions votées unix.stackexchange.com/questions/25372

0 votes

162voto

jpatokal Points 6061

Essayez stdbuf inclus dans GNU coreutils et donc dans pratiquement toutes les distributions Linux. Ceci définit la longueur du tampon pour l'entrée, la sortie et l'erreur à zéro :

stdbuf -i0 -o0 -e0 command

8 votes

Cela a mieux fonctionné que unbuffer pour moi. stdbuf a transmis des signaux ( SIGUSR2 dans mon cas) je l'ai envoyé à la command (ce qui est ce que je voulais que cela se produise), alors que unbuffer ne semblait pas vouloir le faire.

5 votes

Stdbuf utilise l'une des astuces LD_PRELOAD susmentionnées pour ce faire et ne fonctionne donc pas avec les exécutables liés statiquement ou setuid. Voir cette question pour une discussion : stackoverflow.com/questions/13644024/

7 votes

Je l'ai trouvé très utile, mais limité, car il ne lance pas scripts implicitement. Cependant, stdbuf -o0 bash exécute une session complète avec tous mes scripts et alias disponibles, et sans tampon de sortie sur aucune des commandes, ce qui est exactement ce que je voulais. La mise en mémoire tampon a bien sûr été restaurée à la sortie de cette commande bash instance. J'utilise Ubuntu 16.04.

35voto

La commande unbuffer de la expect désactive la mise en mémoire tampon de la sortie :
Page de manuel Ubuntu : unbuffer - débuffer les données de sortie

Exemple d'utilisation :

unbuffer hexdump file | ./my_script

3 votes

Unbuffer semble fusionner stdout et stderr de la commande cependant... ( !)

3 votes

@olejorgenb oui, il fusionne stdout et stderr, c'est à dessein : unbuffer utilise expect, et expect est là pour émuler l'humain dans l'interaction humain-programme, et les humains ne peuvent pas voir si une sortie est stdout ou stderr.

25voto

Nordic Mainframe Points 13717

AFAIK, vous ne pouvez pas le faire sans de vilains bidouillages. L'écriture dans un tube (ou la lecture dans un tube) active automatiquement la mise en mémoire tampon complète et vous ne pouvez rien y faire :-(. Le "Line Buffering" (qui est ce que vous voulez) n'est utilisé que pour lire/écrire dans un terminal. C'est exactement ce que font les vilains hacks : Ils connectent un programme à un pseudo-terminal, de sorte que les autres outils du pipe lisent/écrivent à partir de ce terminal en mode tampon de ligne. L'ensemble du problème est décrit ici :

La page contient également quelques suggestions (les "ugly hacks" susmentionnés) sur ce qu'il faut faire, c'est-à-dire utiliser les éléments suivants unbuffer ou de faire des tours de passe-passe avec LD_PRELOAD .

23voto

vroc Points 211

Vous pouvez également utiliser le script pour que la sortie de hexdump tampon de ligne ( hexdump sera exécuté dans un pseudo terminal qui trompe hexdump en pensant qu'il écrit son stdout dans un terminal, et non dans un pipe).

# cf. http://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe/
stty -echo -onlcr
script -q /dev/null hexdump file | ./my_script         # FreeBSD, Mac OS X
script -q -c "hexdump file" /dev/null | ./my_script    # Linux
stty echo onlcr

0 votes

J'ai utilisé le paramètre -f pour la purge, pas sûr que ce soit nécessaire mais ça a marché.

0 votes

Dans mon cas, stdbuf a échoué, mais script fonctionne comme un charme. Le programme met en mémoire tampon la sortie lorsqu'elle est envoyée à tee mais pas lorsqu'il est exécuté en mode terminal. Donc, script fonctionne ! Merci !

0 votes

Solution très astucieuse, et ça marche ! !! Merci :smile :

0voto

Binghoo Dang Points 1

Il faut utiliser les options grep ou egrep "--line-buffered" pour résoudre ce problème. aucun autre outil n'est nécessaire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X