[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: the zen of SIGPIPE
>>> I think that it would be more useful for xargs to raise(2) certain
>>> signals which terminated its child rather than write to stderr.
>> Um. Wow. I hadn't thought of that, but it superficially makes a
>> whole lot of sense. I want to think about it a bit.
>> Of course, figuring out exactly which signals should get this
>> treatment is likely to be a bikeshed. SIGPIPE, yes, but beyond
>> that? I'm not sure.
> As for signals, well, it probably makes sense to also propagate
> SIGINT this way.
I'm not so sure.
If SIGINT is tty-generated, it will hit the whole process group
already. If that hits xargs, there's no need to push it up; if it
doesn't, there's probably a reason and it arguably shouldn't.
Similar remarks apply to other tty-generated signals.
Non-tty-generated instances of signals which are normally
tty-generated, like SIGINT...I'm not sure. I'm tempted to say that
they're rare enough there's no point in taking any particular measures
SIGSTOP, I'm inclined to agree.
I do think there should be flags to control all this.
> [...] may be quite important for allowing interactive use to proceed
> the way that you expect.
I'm not even sure what "the way that [I] expect" is, much less how
similar it is to the way you expect....
/~\ 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 |