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