4 ms·
> Another default behavior, killing the program on SIGPIPE is also optimized for those programs I've never understood this choice myself. It has always seemed
by steeleduncan 8y ago
> Another default behavior, killing the program on SIGPIPE is also optimized for those programs
I've never understood this choice myself. It has always seemed unhelpful given that the read/write returns an error anyhow. Why is it a helpful default?
- mjw1007 8y agoYou might be piping its output into `head` or `more`.
- ajross 8y agoExactly. Also it generally relies on every process everywhere to properly handle an error return from write(). If you launch a big pipe from the shell and just one stage goofs this up and keeps writing after error, the whole thing will stall until you Ctrl-C or otherwise manually kill the process group, which will wreck whatever result you were trying to get from the (already completed successfully!) "head" or "cut" or whatever. Basically it's a very sane robustness choice and one of the great ideas of classic unix. It's just surprising the first time you stumble over it.