Desativar o buffer no tubo

Eu tenho um script que chama dois comandos:

long_running_command | print_progress

As long_running_commandimpressões de um progresso, mas eu estou infeliz com ele. Estou usando print_progresspara torná-lo mais agradável (ou seja, imprimo o progresso em uma única linha).

O problema: conectar um pipe ao stdout também ativa um buffer de 4K, para o bom programa de impressão não recebe nada ... nada ... nada ... muito ... :)

Como posso desativar o buffer 4K do long_running_command(não, não tenho a fonte)?

Você pode usar o unbuffercomando (que faz parte do expectpacote), por exemplo

unbuffer long_running_command | print_progress

unbufferconecta-se long_running_commandatravés de um pseudoterminal (pty), que faz com que o sistema o trate como um processo interativo, portanto, não usa o buffer de 4 kiB no pipeline, que é a causa provável do atraso.

Para pipelines mais longos, pode ser necessário descomprimir cada comando (exceto o final), por exemplo

unbuffer x | unbuffer -p y | z

Outra maneira de esfolar esse gato é usar o stdbufprograma, que faz parte do GNU Coreutils (o FreeBSD também possui um).

stdbuf -i0 -o0 -e0 command

Isso desativa o buffer completamente para entrada, saída e erro. Para algumas aplicações, o buffer de linha pode ser mais adequado por razões de desempenho:

stdbuf -oL -eL command

_{Observe que ele funciona apenas para stdiobuffer ( printf(), fputs()...) para aplicativos vinculados dinamicamente e somente se esse aplicativo não ajustar o buffer de seus fluxos padrão sozinho, embora isso deva cobrir a maioria dos aplicativos.}

Outra maneira de ativar o modo de saída com buffer de linha long_running_commandé usar o scriptcomando que executa o seu long_running_commandem um pseudo terminal (pty).

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

Para grep, sede awkvocê pode forçar a saída a ser buffer de linha. Você pode usar:

grep --line-buffered

Força a saída a ser buffer de linha. Por padrão, a saída é buffer de linha quando a saída padrão é um terminal e o buffer do bloco é contrário.

sed -u

Tornar a linha de saída em buffer.

Consulte esta página para obter mais informações: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

Se houver um problema com a libc modificando seu buffer / liberação quando a saída não for para um terminal, tente socat . Você pode criar um fluxo bidirecional entre quase qualquer tipo de mecanismo de E / S. Um deles é um programa bifurcado falando com uma pseudo-tty.

 socat EXEC:long_running_command,pty,ctty STDIO 

O que faz é

• crie um pseudo-tty
• fork long_running_command com o lado escravo do pty como stdin / stdout
• estabelecer um fluxo bidirecional entre o lado mestre do pty e o segundo endereço (aqui é STDIO)

Se isso lhe der a mesma saída que long_running_command, então você pode continuar com um tubo.

Edit: Uau Não vi a resposta do buffer! Bem, o socat é uma ótima ferramenta de qualquer maneira, então eu posso deixar essa resposta

Você pode usar

long_running_command 1>&2 |& print_progress

O problema é que a libc faz buffer de linha quando o stdout é exibido na tela e buffer total quando o stdout é exibido em um arquivo. Mas sem buffer para stderr.

Eu não acho que seja o problema com o buffer de pipe, é tudo sobre a política de buffer da libc.

Costumava ser o caso, e provavelmente ainda é o caso, de que quando a saída padrão é gravada em um terminal, a linha é armazenada em buffer por padrão - quando uma nova linha é gravada, a linha é gravada no terminal. Quando a saída padrão é enviada para um tubo, ela é totalmente armazenada em buffer - portanto, os dados são enviados apenas para o próximo processo no pipeline quando o buffer de E / S padrão é preenchido.

Essa é a fonte do problema. Não tenho certeza se há muito que você pode fazer para corrigi-lo sem modificar a gravação do programa no canal. Você pode usar a setvbuf()função com o _IOLBFsinalizador para colocar incondicionalmente stdoutno modo de buffer de linha. Mas não vejo uma maneira fácil de aplicar isso em um programa. Ou o programa pode fazer fflush()nos pontos apropriados (após cada linha de saída), mas o mesmo comentário se aplica.

Suponho que, se você substituísse o pipe por um pseudo-terminal, a biblioteca de E / S padrão pensaria que a saída era um terminal (porque é um tipo de terminal) e alinharia o buffer automaticamente. Essa é uma maneira complexa de lidar com as coisas, no entanto.

Sei que essa é uma pergunta antiga e já tinha muitas respostas, mas se você deseja evitar o problema do buffer, tente algo como:

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

Isso produzirá os logs em tempo real e também os salvará no logs.txtarquivo, e o buffer não afetará mais o tail -fcomando.

Não acho que o problema esteja com o cano. Parece que seu processo de execução demorada não está liberando seu próprio buffer com frequência suficiente. Alterar o tamanho do buffer do canal seria um truque para contorná-lo, mas não acho possível sem reconstruir o kernel - algo que você não gostaria de fazer como um hack, pois provavelmente a aversley afeta muitos outros processos.

De acordo com este post aqui , você pode tentar reduzir o ulimit do pipe para um único bloco de 512 bytes. Certamente não desativará o buffer, mas bem, 512 bytes é muito menor que 4K: 3

Da mesma forma que a resposta de Chad , você pode escrever um pequeno script como este:

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

Em seguida, use este scripteecomando como um substituto para tee.

my-long-running-command | scriptee

Infelizmente, não consigo obter uma versão como essa para funcionar perfeitamente no Linux, então parece limitada aos unixes no estilo BSD.

No Linux, isso está próximo, mas você não recebe seu prompt de volta quando ele termina (até você pressionar enter, etc) ...

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

Encontrei esta solução inteligente: (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

Isso faz o truque. catlerá a entrada adicional (até EOF) e a passará para o canal depois de echocolocar seus argumentos no fluxo de entrada de shell_executable.

De acordo com isso, o tamanho do buffer do pipe parece estar definido no kernel e exigiria que você recompile seu kernel para alterar.