Re: "wait" loses signals

[Robert Elz]

    Date:        Mon, 24 Feb 2020 06:44:12 -0800
    From:        "Daniel Colascione" <dancol@dancol.org>
    Message-ID:  <b79fe5b2cd279fb9ad93ae0180dd97d5.squirrel@dancol.org>

  | That executing traps except in case you lose one rare race is painfully
  | obvious.

Maybe you misunderstand the issue, no traps are lost, if they were
that would indeed be a bug, the trap will always be executed in the
cases in question, the only issue is when that happens.

  | I refuse to let the standard cap the quality of a shell's implementation.

So you should.   No-one is suggesting that there is any reason that
any shell cannot do this better, if the authors feel the cost trade
off is worth the benefit.

  | Missing signals [...]

Since this appears to be based upon a misunderstanding, I will ignore that.

  | A standard is a bare minimum.

That's close enough to correct.

  | This opposition to doing more than the bare minimum that the standard
  | requires makes this task all the much harder.

I am not at all opposed to doing more than the standard requires, the
shell I maintain does more (not nearly as many addons as bash, but
considerably more than bash - and in some areas we're ahead, we already
have a wait command where it is possible to wait for any one of a set
of processes (or jobs) and be told which one completed, for example).

I'm also not opposed to doing less when the standard is nonsense, which
it is in a couple of places.

But "I want x" or "I think it should be y" aren't good enough reasons to
change something, and making the shell useful for (very primitive) IPC
isn't a good reason for making updates.

  | Making people go elsewhere *on purpose* by refusing to fix bugs is not
  | good software engineering.

Of course.   I don't see a bug.

  | We're talking about fixing an existing shell feature, not adding a new one.

OK, here's an alternative, I want the shell to be able to do arithmetic on
arbitrarily large (and small) numbers.   All that is needed to fix it is
to link in the bignum library and use it (and extend the parser a little to
handle real numbers).   Can I call it a bug that bash only does arithmetic
on integers, and has a limit on their size (64 bits I believe), and demand
that Chet fix it?    Know that I am perfectly aware that the standard doesn't
require what I want, but remember that is the bare minimum, we can do better
(bash already does, 32 bits is all that is required, as I remember).

  | This moralistic outlook is not helpful. It doesn't *matter* whether a
  | program is right or wrong or making unjustified assumptions or not.

That is unbelievable.   That is all that matters.   If the program is
wrong, the program needs to be fixed, not the world altered so that the
program suddely works.

  | Punishing programs does not make the world does not make the world better.

It does.   The bad ones fail, and are replaced by better ones.

kre