[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: why complain about a broken pipe?
>>> The shell reports the return status only of the last process in a
>> Depends on the shell and the status. [...]
> I'm not sure what you mean.
> $ yes | grep . | cat > /dev/null && echo OK&
> $ pkill grep
>  Broken pipe yes |
> Terminated grep . |
> Done cat >/dev/null
> I see the shell printing messages about the exit status of each
That's what I meant. I assumed "reporting" meant, well, reporting.
> I do not see a way to act on yes's return status in a shell script.
Neither do I. It was not clear to me that's what you meant by the
shell "report[ing]" the status of a process. I do not see this as a
failing; I do not expect the shell to be a fully general subprocess
> $ find /usr | xargs ls -F | grep / | head -2
> I don't see any reason to report errors writing to standard output.
> If there were one, all four utilities in my example would have
> complained, [...]
Actually, I think find and grep should not complain, but the shell
could reasonably - perhaps optionally - report on their behalf when it
sees them die showing SIGPIPE.
xargs is a less clear-cut case, since xargs didn't get SIGPIPE; it's
the ls run by xargs that did. I'm not sure what I think the right
thing is there.
> and we all would have switched to another computing facility 35 years
Maybe you would have. I don't see any grounds for your apparent
assumption that "we all" share your attitude in this regard.
There are plenty of cases where I _do_ want to hear about SIGPIPE
deaths, perhaps most notably (but not exclusively) as applied to
network connections. But, as you point out, there are also plenty of
cases where it's pointless or undesirable. Hence my uncertainy what
the right thing is here.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |