> There are lots of programming languages around, they each have their > particular > niche - the reason their inventors created them in the first place. Use > an > appropriate one, rather than attempting to shoehorn some feature that is > needed > into a language that was never intended for it - just because you happen > to > be a big fan of that language. Spread your wings, learn a new one
That is a poor excuse for not fixing bugs. Maybe you can torture the standards into confessing that this behavior isn't a bug. This behavior nevertheless surprises people and nevertheless precludes various things people want to do with a shell. Don't you think it's better that programs work reliably than that they don't? Of course something working intuitively 99.9% of the time and hanging 0.1% of the time is a bug. It's not appropriate to treat that 0.1% hang as some kind of cosmic punishment for using shell in a manner you find inappropriate: remember when we believed in mechanism, not policy? Nor is the presence of the bug in other shells adequate justification for leaving this one in a bad state. I've never understood the philosophy of people who want to leave bugs unfixed. No, it's not that much trouble to fix the bug. The techniques for fixing this kind of signal race are well-known. In particular, instead of waitpid, you use a self-pipe and signal the pipe in the signal handler, and you have a signal handler for SIGCHLD. If we had a pwaitpid (like pselect) we could use that too. If I could get Chet to look at my patches, I'd fix it myself.