tech-userlevel archive

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

Re: the zen of SIGPIPE

> FWIW, I agree with jkl that outputting ``xargs: <foo> terminated by
> SIGPIPE'' is not terribly helpful.  [...]

> At first glance, it would seem that xargs will output the message if
> the command after the pipe does not consume all of output generated
> by the commands that it runs, however, this is incorrect.

> [...pipe buffering...races...]

This is a very good point and is easily the best argument I have seen
for the stance that xargs should not print reports 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

> This is coincidentally how some shells deal with receiving SIGINT to
> ensure that it propagates to parent shells so that they can, e.g.
> terminate loops.

> $ cat /tmp/foo
> #!/bin/sh
> echo "$@"
> kill -2 $$
> sleep 1

> $ for i in $(jot 3); do /tmp/foo foo bar baz; done             
> foo bar baz

That's not what I see (NetBSD/sparc 1.4T and NetBSD/i386 4.0.1); I get
three "foo bar baz" lines.  What shell do you see this with?  Have you
checked (eg, ktrace) that it really is the shell passing on the signal
rather than something else?

> All that said, it appears that the standards suggest that we keep our
> current behaviour and so I am a bit divided.  I think that the
> current behaviour is not optimal, however, we should be careful about
> diverging from the standard as this may have unintended consequences.

Well, standard xargs is already so broken for most uses it's
ridiculous.  (Treating non-newline whitespace as separators is one
example; mangling lines containing ', ", and \ is another.  Providing
options to handle quoting is, maybe, reasonable, though I can't think
of a case where that's what I've wanted; requiring users to resort to
tr \\n \0 | xargs -0 to avoid quoting is, IMO, not.  I long ago wrote
myself an xargs that works in ways I find more useful, including far
more flexible specifications of the commands to run.)

I'll have to think about the "push signals upwards" suggestion;
currently my xargs completely ignores child exit status.  I'm inclined
to implement it, but want to give it a day or two to percolate and see
if anything comes to mind I haven't thought of immediately.

/~\ 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