I have a script which calls two commands:
long_running_command | print_progress
The long_running_command prints progress but I'm unhappy with it. I'm using print_progress to make it nicer (namely, I print the progress in a single line).
The problem: Connection a pipe to stdout also activates a 4K buffer, so the nice print program gets nothing ... nothing ... nothing ... a whole lot ... :)
How can I disable the 4K buffer for the long_running_command (no, I do not have the source)?
Another way to skin this cat is to use the stdbuf program, which is part of the GNU Coreutils (FreeBSD also has its own one).
stdbuf -i0 -o0 -e0 command
This turns off buffering completely for input, output and error. For some applications, line buffering may be more suitable for performance reasons:
stdbuf -oL -eL command
Note that it only works for stdio buffering (printf(), fputs()...) for dynamically linked applications, and only if that application doesn't otherwise adjust the buffering of its standard streams by itself, though that should cover most applications.
stdbuf does not work with tee, because tee overwrites the defaults set by stdbuf. See the manual page of stdbuf.
stdbuf uses LD_PRELOAD mechanism to insert its own dynamically loaded library libstdbuf.so. This means that it will not work with these kinds executables: with setuid or file capabilities set, statically linked, not using standard libc. In these cases it is better to use the solutions with unbuffer / script / socat. See also stdbuf with setuid/capabilities.
Oct 12, 2015 at 9:20
You can use the unbuffer command (which comes as part of the expect package), e.g.
unbuffer long_running_command | print_progress
unbuffer connects to long_running_command via a pseudoterminal (pty), which makes the system treat it as an interactive process, therefore not using the 4-kiB buffering in the pipeline that is the likely cause of the delay.
For longer pipelines, you may have to unbuffer each command (except the final one), e.g.
unbuffer x | unbuffer -p y | z
expect_unbuffer and is in the expect-dev package, not the expect package
expect-dev provides both unbuffer and expect_unbuffer (the former is a symlink to the latter). The links are available since expect 5.44.1.14-1 (2009).
unbuffer is in the main expect package on debian now (it's still a symlink to expect_unbuffer, which is also in the main expect package)
For grep, sed and awk you can force output to be line buffered. You can use:
grep --line-buffered
Force output to be line buffered. By default, output is line buffered when standard output is a terminal and block buffered other-wise.
sed -u
Make output line buffered.
See this page for more information: http://www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html
python also supports the -u parameter to disable buffering.
Dec 19, 2019 at 21:52
long_running_command it's too late. It'll be buffered before it even gets to grep.
Jan 24, 2020 at 15:26
grep --line-buffered pattern *many*many*files* | head? It looks like grep processes all the files before feeding the output lines to head
Yet another way to turn on line-buffering output mode for the long_running_command is to use the script command that runs your long_running_command in a pseudo terminal (pty).
script -q /dev/null long_running_command | print_progress # (FreeBSD, Mac OS X)
script -q -c "long_running_command" /dev/null | print_progress # (Linux)
script is such an old command, it should be available on all Unix-like platforms.
Jan 20, 2013 at 13:01
-q on Linux: script -q -c 'long_running_command' /dev/null | print_progress
stdin, which makes it impossible to run such a long_running_command in the background, at least when started from interactive terminal. To workaround, I was able to redirect stdin from /dev/null, since my long_running_command doesn't use stdin.
script worked for me where stdbuf did not. Use script -e -c <cmd> /dev/null if you want script to return the exit code of <cmd>.
If it is a problem with the libc modifying its buffering / flushing when output does not go to a terminal, you should try socat. You can create a bidirectional stream between almost any kind of I/O mechanism. One of those is a forked program speaking to a pseudo tty.
socat EXEC:long_running_command,pty,ctty STDIO
What it does is
If this gives you the same output as long_running_command, then you can continue with a pipe.
Edit : Wow Did not see the unbuffer answer ! Well, socat is a great tool anyway, so I might just leave this answer
socat -u exec:long_running_command,pty,end-close - here
Aug 7, 2015 at 13:10
You can use
long_running_command 1>&2 |& print_progress
The problem is that libc will line-buffer when stdout to screen and block-buffer when stdout to a file, but no-buffer for stderr.
I don't think it's the problem with pipe buffer, it's all about libc's buffer policy.
zsh (where |& comes from adapted from csh) and bash, when you do cmd1 >&2 |& cmd2, both fd 1 and 2 are connected to the outer stdout. So it works at preventing buffering when that outer stdout is a terminal, but only because the output doesn't go through the pipe (so print_progress prints nothing). So it's the same as long_running_command & print_progress (except that print_progress stdin is a pipe that has no writer). You can verify with ls -l /proc/self/fd >&2 |& cat compared to ls -l /proc/self/fd |& cat.
Aug 7, 2015 at 10:44
|& is short for 2>&1 |, literally. So cmd1 |& cmd2 is cmd1 1>&2 2>&1 | cmd2. So, both fd 1 and 2 end up connected to the original stderr, and nothing is left writing to the pipe. (s/outer stdout/outer stderr/g in my previous comment).
Aug 7, 2015 at 10:48
It used to be the case, and probably still is the case, that when standard output is written to a terminal, it is line buffered by default - when a newline is written, the line is written to the terminal. When standard output is sent to a pipe, it is fully buffered - so the data is only sent to the next process in the pipeline when the standard I/O buffer is filled.
That's the source of the trouble. I'm not sure whether there is much you can do to fix it without modifying the program writing into the pipe. You could use the setvbuf() function with the _IOLBF flag to unconditionally put stdout into line buffered mode. But I don't see an easy way to enforce that on a program. Or the program can do fflush() at appropriate points (after each line of output), but the same comment applies.
I suppose that if you replaced the pipe with a pseudo-terminal, then the standard I/O library would think the output was a terminal (because it is a type of terminal) and would line buffer automatically. That is a complex way of dealing with things, though.
I know this is an old question and already had lot of answers, but if you wish to avoid the buffer problem, just try something like:
stdbuf -oL tail -f /var/log/messages | tee -a /home/your_user_here/logs.txt
This will output in real time the logs and also save them into the logs.txt file and the buffer will no longer affect the tail -f command.
NOTE: If COMMAND adjusts the buffering of its standard streams ('tee' does for example) then that will override corresponding changes by 'stdbuf'.
Sep 17, 2019 at 20:58
I don't think the problem is with the pipe. It sounds like your long running process is not flushing its own buffer frequently enough. Changing the pipe's buffer size would be a hack to get round it, but I don't think its possible without rebuilding the kernel - something you wouldn't want to do as a hack, as it probably aversley affect a lot of other processes.
In a similar vein to chad's answer, you can write a little script like this:
# save as ~/bin/scriptee, or so
script -q /dev/null sh -c 'exec cat > /dev/null'
Then use this scriptee command as a replacement for tee.
my-long-running-command | scriptee
Alas, I can't seem to get a version like that to work perfectly in Linux, so seems limited to BSD-style unixes.
On Linux, this is close, but you don't get your prompt back when it finishes (until you press enter, etc)...
script -q -c 'cat > /proc/self/fd/1' /dev/null
script emulates a terminal, so yes, I believe it turns off buffering. It also echoes back each character sent to it - which is why cat is sent to /dev/null in the example. As far as the program running inside script is concerned, it is talking to an interactive session. I believe it's similar to expect in this regard, but script likely is part of your base system.
tee is to send a copy of the stream to a file. Where does the file get specified to scriptee?
Jul 31, 2019 at 19:26
cat command with tee myfile.txt, and you should get the effect you want.
jq has --unbuffered flag:
Flush the output after each JSON object is printed (useful if you're piping a slow data source into jq and piping jq's output elsewhere).
--unbuffered flag. I've just been trying to pipe the output of mosquitto_sub to jq in a Git Bash terminal. I'm troubleshooting a hardware problem, and I need a 'live' readout of a few values. The messages that get splatted to the terminal are too big to see clearly, so I wanted to filter them using jq, got bit by this exact same buffering behavior. Using jq --unbuffered solved it neatly, thank you!
Nov 14, 2023 at 3:12
Python has the -u (unbuffered) flag.
$ man python3
[...]
-u Force the stdout and stderr streams to be unbuffered. This option has no effect on the stdin stream.
[...]
I found this clever solution: (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable
This does the trick. cat will read additional input (until EOF) and pass that to the pipe after the echo has put its arguments into the input stream of shell_executable.
cat doesn't see the the output of the echo; you just run two commands in a subshell and the output of both is sent into the pipe. The second command in the subshell ('cat') reads from the parent/outer stdin, that's why it works.
Nov 9, 2016 at 11:19
According to this post here, you could try reducing the pipe ulimit to one single 512-byte block. It certainly won't turn off buffering, but well, 512 bytes is way less than 4K :3
According to this the pipe buffer size seems to be set in the kernel and would require you to recompile your kernel to alter.
