tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sh: killing a pipe head from the tail

>> and the obvious solution (apart from patching collectd) is to trap -
>> PIPE before calling envstat.
> That would not have worked, non-interactive shells are forbidden from
> allowing the script to change the status of a signal which is ignored
> when the shell starts: [...POSIX...]

Then POSIX is broken and there needs to be a way to disable this
particular bit of braindamage; a script breaking because some signal it
depends on happens to have been left ignored by its parent is, well,
broken, and POSIX mandating that the script be gratuitously prevented
from fixing it is, IMO, a bug in POSIX.

> [...] "jobid" builtin [...]

> mouse%Rodents-Montreal.ORG@localhost said:
>> I'm not sure what I think of the idea that a pipe's reader can do
>> things to the pipe's writer without the writer's cooperation.
> I agree with that - but this isn't quite that, [...]

Correct, it isn't.  When this is done by, or (as here) with the
cooperation of, the parent shell, I see no problem with it.  It's only
when it's a pipe reader unilaterally fiddling with the pipe's writer(s)
without anyone else's cooperation that my "eh, not sure about that"
flags go up.

I'm not sure why I'm not equally bothered by possible answers using
fstat to ferret out the PID(s) of the writer(s).  I suspect it's
related to the reasons that, despite "userland shouldn't be able to
panic the kernel" dicta, "dd if=/dev/zero of=/dev/mem" crashing things
doesn't bother me.  But I'm not sure what those reasons are; I haven't
found a satisfactory statement of them.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index