Comment by BoingBoomTschak | Hacker News Reader

Comment by BoingBoomTschak | Hacker News Reader

BoingBoomTschak

Also made a post some time ago about the issue: 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/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.

I 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);
   }
  }

I'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.

Reply on news.ycombinator.com