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
