Hacker News Reader

Comment by dooglius | Hacker News Reader

This is bad advice, if you are doing anything other than output to stdout/stderr (which you almost assuredly are, unless you are doing something very simple like "yes"), you want to switch to /dev/null. For instance, running

  rm -vfr folder/ | head

involves SIGPIPE causing problems because it may or may not kill rm before it finishes deleting the directory, based on its internal output buffer size.

View on HN

The problem here is connecting a program you want to run to completion to the head command, not how rm handles SIGPIPE.

head is just an example, if you pipe rm -vfr (or any program that does more than just output) into _anything_ the reasonable and default behavior should be to run rm to completion. (And from a programmer's POV, the reasonably thing is for syscalls to handle errors by returning an error, the way every other error is handled.)

Wouldn't it be better to be explicit? If intention is to "display first 10 lines, at most; discard the rest", you can write:

  rm -vrf directory/ | (head; cat >/dev/null)

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.

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

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

rm doesn't print anything on stdout.

"rm -v" does.

Reply on news.ycombinator.com