Re: "wait" loses signals

[Daniel Colascione]

>     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.

They're not executed before the wait as is supposed to happen though, so
we can hang when we shouldn't.

>   | 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.

Yes, it is, because people find this style of IPC useful today, and it's
worthwhile to make this use reliable.

>   | Making people go elsewhere *on purpose* by refusing to fix bugs is not
>   | good software engineering.
>
> Of course.   I don't see a bug.

You can interpret any random bit of brokenness as a feature. Whether the
behavior is a "bug" or not is irrelevant: bash _should_ be handling these
traps as early as possible, because that simplifies the programming model
without hurting anything else.

>   | 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).

This situation is more like bash supporting arbitrary-precision addition
and giving the wrong answer when the number is prime. "Oh, we never
promised support for _prime_ sums. It's not a bug. It's just a thing the
shell doesn't do."


>   | 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.

You want to increase the number of correct programs in the world.
Sometimes the fix is to declare incorrect programs broken and have people
fix them. Other times, in situations like this one, it's better to just
change the infrastructure so that the program is correct.

>
>   | 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.

Computer security was even more of a horrible nightmare than it is today
back when people had this attitude. "Why should we use stack hardening? If
a program writes beyond the end of an array, that's a bug in the program."
Nice sentiment. Doesn't work.