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