Выключите буферизацию в канале

Другой способ освежевать эту кошку состоит в том, чтобы использовать stdbuf программа, которая является частью Coreutils GNU (FreeBSD также имеет свой собственный).

stdbuf -i0 -o0 -e0 command

Это выключает буферизацию полностью для входа, вывода и ошибки. Для некоторых приложений буферизация строки может более подойти по причинам производительности:

stdbuf -oL -eL command

_{Обратите внимание, что это только работает на stdio буферизация (printf(), fputs()...) для динамично связанных приложений, и только если то приложение иначе не корректирует буферизацию своих стандартных потоков отдельно, хотя это должно покрыть большинство приложений.}

Если это - проблема с libc изменение его буферизации / сбрасывание, когда произведенный не переходит к терминалу, необходимо попробовать socat. Можно создать двунаправленный поток почти между любым видом механизма ввода-вывода. Один из тех является разветвленной программой, говорящей с псевдо tty.

 socat EXEC:long_running_command,pty,ctty STDIO 

То, что это делает,

• создайте псевдо tty
• ветвление long_running_command с ведомой стороной имущества как stdin/stdout
• установите двунаправленный поток между основной стороной имущества и вторым адресом (здесь, это - STDIO),

Если это дает Вам тот же вывод как long_running_command, затем можно продолжить канал.

Редактирование: Ничего себе, не видел освобождать буфер ответ! Ну, socat является большим инструментом так или иначе, таким образом, я мог бы просто оставить этот ответ

Это раньше имело место и вероятно все еще имеет место, что, когда стандартный вывод записан в терминал, это - строка, буферизованная по умолчанию - когда новая строка записана, строка записана в терминал. Когда стандартный вывод отправляется в канал, он полностью буферизуется - таким образом, данные только отправляются в следующий процесс в конвейере, когда стандартный буфер ввода-вывода заполнен.

Это - источник проблемы. Я не уверен, существует ли очень, можно сделать для фиксации его, не изменяя программу, пишущую в канал. Вы могли использовать setvbuf() функция с _IOLBF отметьте для безусловного помещения stdout в строку буферизовал режим. Но я не вижу простой способ осуществить это на программе. Или программа может сделать fflush() в соответствующих точках (после каждой строки вывода), но тот же комментарий применяется.

Я предполагаю, что при замене канала псевдотерминалом, затем стандартная библиотека I/O думала бы, что вывод был терминалом (потому что это - тип терминала), и выровнял бы буфер автоматически. Это - сложный способ иметь дело с вещами, все же.

Я не думаю, что проблема с каналом. Это кажется, что Ваш длительный процесс не сбрасывает свой собственный буфер достаточно часто. Изменение размера буфера канала было бы взломом для обхода его, но я не думаю его возможное, не восстанавливая ядро - что-то, что Вы не хотели бы делать как взлом, поскольку это, вероятно, неохотно влияет на большое количество других процессов.

Согласно этому размер буфера канала, кажется, установлен в ядре и потребовал бы, чтобы Вы перекомпилировали свое ядро для изменения.

Для grep, sed и awk можно вынудить вывод быть буферизованной строкой. Можно использовать:

grep --line-buffered

Вывод силы, чтобы быть буферизованной строкой. По умолчанию вывод является строкой, буферизованной, когда стандартный вывод является терминалом и блоком, буферизованным иначе.

sed -u

Сделайте выходную строку буферизованной.

Посмотрите эту страницу для получения дополнительной информации: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

Еще один способ включить буферизующий строку режим вывода для long_running_command должен использовать script управляйте что выполнения Ваш long_running_command в псевдотерминале (имущество).

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

Вы можете использовать

long_running_command 1>&2 |& print_progress

Проблема в том, что libc будет буферизовать строку при выводе из стандартного потока на экран и в полном буфере при выводе из файла в файл. Но без буфера для stderr.

Я не думаю, что проблема с буфером конвейера, все дело в политике буферов libc.

Я знаю, что это старый вопрос, на который уже было много ответов, но если вы хотите избежать проблемы с буфером, просто попробуйте что-нибудь вроде:

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

Это будет выводить журналы в реальном времени, а также сохранять их в файл logs.txt , и буфер больше не влияет на команду tail -f .

Я нашел это умное решение: (echo -e "cmd 1 \ ncmd 2" && cat) | ./shell_executable

Это трюк. cat будет читать дополнительный ввод (до EOF) и передавать его конвейеру после того, как echo поместит свои аргументы во входной поток shell_executable .

Подобно ответу chad , вы можете написать небольшой скрипт вроде этого:

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

Затем используйте эту команду scriptee вместо tee ].

my-long-running-command | scriptee

Увы, похоже, я не могу заставить такую ​​версию идеально работать в Linux, поэтому, похоже, ограничивается unix-системами в стиле BSD.

В Linux это близко, но вы не получите обратно приглашение, когда оно закончится (пока вы не нажмете Enter и т. Д.) ...

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