from Robert Elz: > I have just committed the (long awaited) bug fix set for /bin/sh -- > to fix some bugs I introduced recently - but also, several old, > devious, bugs that had remained hidden for years, but which became > more exposed with some of the recent changes - not so much the changes > themselves, but with the way the code changed to accommodate easier > debugging of the changes.
> So please watch for anything that looks like it could be shell misbehaviour, > and either let me know, or file a PR. > You might also want to consider rebuilding anything that has been built from > a shell script (particularly a large one - like a configure script) in the > past couple of weeks. While it is very unlikely that a bug could have > caused the script to fail in a way that would not be immediately obvious, > with some of what has been fixed, almost anything is possible. Note it is > not so much the complexity of the script that matters, but the amount of > data processed (strings expanded, ...) which would trigger problems, so a > small script that collects, massages, then outputs, a lot of variable > length (but probably normally lengthy) data is far more likely to have been > affected than a huge set of functions that work on a relatively small data > set. I guess bugs in sh could affect a run with pkg_rolling-replace and other updates using pkgsrc? I suppose strange things can happen? Am I advised to rebuild my system (i386 and amd64) using build.sh after "cvs up -dP -A"? I will still have the dubious /bin/sh from just this past week. Or should I rebuild twice, the second time being with the new /bin/sh, or is that overkill? Tom