This is just a general "be on the lookout" warning, I have been testing the patches that are about to be applied for w while now, and everything looks good to me, but ...
The previous patches I have (indirectly, with Christos' help) applied to the shell have all been obvious (even where I screwed up and got them wrong, those problems were just my stupidity - not anything devious or strange that wasn't understood.) This time that isn't the case, at least for 2 of the 3 patches that are about to be applied. The third one (the one that won't be a problem) is the trivial fix for PR bin/50896 Of the other two, one is two very small fixes to fix the two (different, but related) bugs reported in PR bin/50834 Those two are both related to the hack that makes "$@" work - and amount to hacks to the hack. I believe they are correct, and I have tested as many different things that I can think of to test, and that all works, but of course, it is always the thing that was never considered that actually breaks. I am confident that in ordinary operation there won't be a problem, but I an slightly less confident that there isn't some strange script out in the wild (maybe some package autoconf script, or similar) that does something I never even thought of trying, and for some reason, it breaks. The other change is the speedup to the parser I mentioned in (one of) my reply to David Holland's message on [email protected] with the Subject: performance of shell read loops This one I have been testing for weeks, but it is the kind of change that might be bitten by unforeseen race conditions, particularly related to syntax errors in strange placed, or signals at particularly bad times. I believe there should be no problems, but this kind of thing is just about impossible to verify by testing. If either of these changes gives problems, please anyone who has access, just revert them, and then send me the details of what went wrong, so I san figure out how to fix it. For the first change (which affects src/bin/sh/expand.c) the trigger will certainly be some form of variable expansion, which would produce an incorrect value, so if you find something that breaks, I'd appreciate knowing (if you can work it out) what it was probably attempting to do at the time. The other could happen any time, and will (if there happens to be a problem) probably just lead to random strange behaviour, perhaps in ways that are not reproducible - though it it happens because of some strange script syntax error it might repeat itself. This one changes src/bin/sh/parser.c There are also a bunch of updates to the ATF tests for sh, more of them (will) now use TEST_SH (from your environment - if not set, /bin/sh as it used to mostly use) as the shell to test (they are not all converted yet, but it is coming.) These (even if they were broken - and I doubt that they are) will of course only affect runs of the test suite, and should at worst result in some bogus test failure results. kre
