Comment by dooglius | Hacker News Reader

Comment by dooglius | Hacker News Reader

Parent Full thread

I guess it depends on your semantics/mental model of what a pipeline should do. My mental model says that each part should run fully, and the pipeline should emulate sequential behavior, with "yes" being a bit of a hack in this regard. Cases where the behavior of a pipeline depends on the internal buffer size and operation ordering (e.g. what if rm decided to print everything it did only after removing everything?) seem like bugs to me. Maybe your mental model is different?

In any case, I think that in the vast majority of pipelines, the default SIGPIPE behavior is not what is desired.

Wishing programs do extra work desroys performance. Some programs run forever unless terminated. If you don't want a program to terminate early, don't send it a termination signal!

The the Unix philosophy is that users are smart and should be obeyed, not that programs should do what they think should have asked for instead. Forcing the user to negotiate with the program like a TARDIS is madness

Piping output of an "rm -v" is an oddball, with all the possible stdio buffering, I agree.

More real-life example fitting your model would be "start this long-running process and show me first 10 lines of output, just to make sure it didn't bail right away", but then, a more common pattern would be to keep a copy of the whole log too:

  myfoo >/var/log/foo & tail -f /var/log/foo | head

Counter-example would be "yes", but also unordered sampling. Let's say I want to know if there is file with "foo" in its name somewhere in a very large directory, just a yes/no. Continuing directory traversal after finding one is a waste of time. SIGPIPE is desirable here as well:

  find directory/ -name '*foo*' | head -1

Reply on news.ycombinator.com