Re: "wait" loses signals

[Robert Elz]

    Date:        Mon, 24 Feb 2020 04:58:31 -0800
    From:        "Daniel Colascione" <dancol@dancol.org>
    Message-ID:  <07d1441d41280e6f95352222048d6485.squirrel@dancol.org>

  | That is a poor excuse for not fixing bugs.

Only if they are bugs.

  | Maybe you can torture the standards into confessing that this
  | behavior isn't a bug.

No torture required.  Once again, the standard documents the way users
can expect shells to behave.  That is what a standard is - a common set
of agreed operations (or whatever is apporpriate for the object being
standardised).   It does not (or should not) ever invent new stuff and
require it.   Shells have always worked this way, so that is how the
standard is written - that is what users can expect to happen (that is why
it is called a "standard" after all).

Once again, you are free to attempt to get shells to change this way of
working, and if you can get a suitable set to agree, and implement something
new, that more meets your needs, then perhaps that might one day become the
standard, and later appear in the standards document.   New and/or changed
features to happen, expecially when they don't break backwards compatibility,
which this wouldn't.

  | This behavior nevertheless surprises people

Lots of things surprise people.

  | and nevertheless precludes various things
  | people want to do with a shell.

That was my point, that you just labelled a poor excuse.   Not everything
is suitable for implementation in sh.   Sometimes you simply have to go
elsewhere.  Wanting to do it in shell doesn't make it reasonable or possible.

I want the shell to feed my dog, where is the dogfood option?

  | Don't you think it's better that programs
  | work reliably than that they don't?

Yes, when they are written correctly.

  | Of course something working intuitively 99.9% of the time and
  | hanging 0.1% of the time is a bug.

Nonsense.   An alternative explanation is that your intuition is wrong,
and that it often works that way is just by chance.   The program is
broken because it is making unjustified assumptions about how things are
specified to work.   This is the kind of common error that people who
program (in any language) by guesswork often make "I saw Fred did this,
and I tried it, and it worked for me like I thought it would, so it
must do this similar thing like I think it will too".   Rubbish.

  | I've never understood the philosophy of people who want to leave
  | bugs unfixed.

Nor have I, except sometimes perhaps when it comes to costs.   But the
issue here is whether this is a bug.  Your belief that it is does not make
it so.

  | No, it's not that much trouble to fix the bug.

It isn't, if it needs fixing - but any fix for this will slow the shell
(for what that matters, but some people care).  Further there are simpler
cheaper techniques than the one described.

  | If we had a pwaitpid (like pselect) we could use that too.

Yes, if.   If that existed a fix would be almost cost free.  If.
I suspect that before you can get bash (note: I am no authority and have
no voice in these decisions, I work on a different shell) to make use
of something like that it would need to be implemented in quite a lot
of systems, including the commercial ones, which tend to be very conservative
about adding new features for fun.

kre