Disattiva il buffering nel pipe

Ho uno script che chiama due comandi:

long_running_command | print_progress

Le long_running_commandstampe sono un progresso ma non sono soddisfatto. Sto usando print_progressper renderlo più bello (vale a dire, stampo l'avanzamento in una sola riga).

Il problema: la connessione di una pipe allo stdout attiva anche un buffer 4K, al bel programma di stampa non si ottiene nulla ... niente ... niente ... molto ... :)

Come posso disabilitare il buffer 4K per il long_running_command(no, non ho il sorgente)?

È possibile utilizzare il unbuffercomando (incluso nel expectpacchetto), ad es

unbuffer long_running_command | print_progress

unbuffersi connette long_running_commandtramite uno pseudoterminale (pty), che fa sì che il sistema lo tratti come un processo interattivo, quindi non utilizzando il buffering a 4 kiB nella pipeline che è la probabile causa del ritardo.

Per pipeline più lunghe, potrebbe essere necessario eseguire il buffering di ciascun comando (tranne quello finale), ad es

unbuffer x | unbuffer -p y | z

Un altro modo per stdbufscuoiare questo gatto è usare il programma, che fa parte del GNU Coreutils (anche FreeBSD ne ha uno proprio).

stdbuf -i0 -o0 -e0 command

Questo disattiva completamente il buffering per input, output ed errori. Per alcune applicazioni, il buffering di linea può essere più adatto per motivi di prestazioni:

stdbuf -oL -eL command

_{Si noti che funziona solo per il stdiobuffering ( printf(), fputs()...) per applicazioni collegate dinamicamente e solo se tale applicazione non regola il buffering dei suoi flussi standard da solo, anche se dovrebbe coprire la maggior parte delle applicazioni.}

Ancora un altro modo per attivare la modalità di output del buffering di linea per il long_running_commandè usare il scriptcomando che esegue il tuo long_running_commandin uno pseudo terminale (pty).

script -q /dev/null long_running_command | print_progress      # FreeBSD, Mac OS X
script -c "long_running_command" /dev/null | print_progress    # Linux

Per grep, seded awkè possibile forzare l'uscita da linea di buffer. Puoi usare:

grep --line-buffered

Forza l'output del buffer di linea. Per impostazione predefinita, l'output è bufferizzato in linea quando l'output standard è un terminale e blocca il buffer in altro modo.

sed -u

Rendere buffer della linea di output.

Vedi questa pagina per maggiori informazioni: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

Se è un problema con libc che modifica il suo buffering / flushing quando l'output non va su un terminale, dovresti provare socat . È possibile creare un flusso bidirezionale tra quasi ogni tipo di meccanismo I / O. Uno di questi è un programma biforcuto che parla con una pseudo tty.

 socat EXEC:long_running_command,pty,ctty STDIO 

Quello che fa è

• creare una pseudo tty
• fork long_running_command con il lato slave del pty come stdin / stdout
• stabilire un flusso bidirezionale tra il lato master del pty e il secondo indirizzo (qui è STDIO)

Se questo ti dà lo stesso output di long_running_command, allora puoi continuare con una pipe.

Modifica: Wow Non ho visto la risposta più spenta! Bene, socat è comunque un ottimo strumento, quindi potrei semplicemente lasciare questa risposta

Puoi usare

long_running_command 1>&2 |& print_progress

Il problema è che libc eseguirà il buffer di riga quando stdout su schermo e buffer completo quando stdout su un file. Ma nessun buffer per stderr.

Non penso che sia il problema con il buffer delle pipe, è tutto sulla politica del buffer di libc.

Una volta era il caso, e probabilmente è ancora il caso, che quando l'output standard è scritto su un terminale, per impostazione predefinita è buffer di riga - quando viene scritta una nuova riga, la riga viene scritta sul terminale. Quando l'output standard viene inviato a una pipe, viene bufferizzato completamente, quindi i dati vengono inviati al processo successivo nella pipeline solo quando il buffer I / O standard è pieno.

Questa è la fonte del problema. Non sono sicuro che ci sia molto da fare per risolverlo senza modificare il programma scrivendo nella pipe. È possibile utilizzare la setvbuf()funzione con il _IOLBFflag per mettere incondizionatamente stdoutin modalità buffer linea. Ma non vedo un modo semplice per imporlo su un programma. Oppure il programma può fare fflush()in punti appropriati (dopo ogni riga di output), ma si applica lo stesso commento.

Suppongo che se si sostituisse la pipe con uno pseudo-terminale, allora la libreria I / O standard penserebbe che l'output fosse un terminale (perché è un tipo di terminale) e allinea automaticamente il buffer. Questo è un modo complesso di trattare le cose, però.

So che questa è una vecchia domanda e aveva già molte risposte, ma se si desidera evitare il problema del buffer, provare qualcosa del tipo:

stdbuf -oL tail -f /var/log/messages | tee -a /home/your_user_here/logs.txt

Ciò genererà in tempo reale i registri e li salverà anche nel logs.txtfile e il buffer non influirà più sul tail -fcomando.

Non penso che il problema sia con la pipa. Sembra che il tuo lungo processo non stia scaricando il proprio buffer abbastanza frequentemente. Cambiare la dimensione del buffer della pipe sarebbe un trucco per aggirarlo, ma non penso che sia possibile senza ricostruire il kernel - qualcosa che non vorresti fare come hack, poiché probabilmente influenzerà molti altri processi.

Secondo questo post qui , potresti provare a ridurre l'ulimit pipe a un singolo blocco da 512 byte. Certamente non disattiverà il buffering, ma bene, 512 byte è molto meno di 4K: 3

Analogamente alla risposta di Chad , puoi scrivere una piccola sceneggiatura come questa:

# save as ~/bin/scriptee, or so
script -q /dev/null sh -c 'exec cat > /dev/null'

Quindi utilizzare questo scripteecomando in sostituzione di tee.

my-long-running-command | scriptee

Purtroppo, non riesco a ottenere una versione come quella che funzioni perfettamente in Linux, quindi sembra limitata agli unix in stile BSD.

Su Linux, questo è vicino, ma non ricevi il tuo prompt al termine (fino a quando premi Invio, ecc.) ...

script -q -c 'cat > /proc/self/fd/1' /dev/null

Ho trovato questa soluzione intelligente: (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

Questo fa il trucco. catleggerà l'input aggiuntivo (fino a EOF) e lo passerà alla pipe dopo che echoha inserito i suoi argomenti nel flusso di input di shell_executable.

In base a ciò, la dimensione del buffer della pipe sembra essere impostata nel kernel e richiederebbe di ricompilare il kernel per modificarlo.