Re: "wait" loses signals

[Robert Elz]

Date:Mon, 24 Feb 2020 06:44:12 -0800
From:"Daniel Colascione" 
Message-ID:  

  | 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

Re: "wait" loses signals

[Daniel Colascione]

> Date:Mon, 24 Feb 2020 06:44:12 -0800
> From:"Daniel Colascione" 
> Message-ID:  
>
>   | 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.