3 ms·
Also made a post some time ago about the issue: https://world-playground-deceit.net/blog/2024/09/bourne_shell_stdio_trivia.html#h2-1 https://world-playground-de
by BoingBoomTschak 2y ago
Also made a post some time ago about the issue: https://world-playground-deceit.net/blog/2024/09/bourne_shell_stdio_trivia.html#h2-1 https://world-playground-deceit.net/blog/2024/09/bourne_shel...
About the commands that don't buffer, this is either implementation dependent or even wrong in the case of cat (cf https://pubs.opengroup.org/onlinepubs/9799919799/utilities/cat.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c... and `-u`). Massive pain that POSIX never included an official way to manage this.
Not mentioned is input buffering, that would gives you this strange result:
$ seq 5 | { v1=$(head -1); v2=$(head -1); printf '%s=%s\n' v1 "$v1" v2 "$v2"; }
v1=1
v2=
The fix is to use `stdbuf -i0 head -1`, in this case.
- jagrsw 2y agoI don't believe a process reading from a pipe/socketpair/whatever can enforce such constraints on a writing process (except using heavy hackery like ptrace()). While it might be possible to adjust the pipe buffer size, I'm not aware of any convention requiring standard C I/O to respect this. In any case, stdbuf doesn't seem to help with this: $ ./a | stdbuf -i0 -- cat #include <stdio.h> #include <unistd.h> int main(void) { for (;;) { printf("n"); usleep(100000); } }
- BoingBoomTschak 2y agoI'm sorry, but I don't understand what you're meaning. The issue in your example is the output buffering of a, not the input buffering of cat. You'd need `stdbuf -o0 ./a | cat` there.