Re: HEADS-UP: /bin/sh memory management bug fixes committed

[Alistair Crooks <agc%pkgsrc.org@localhost>]

I just wanted to say a big thanks for looking after our shell; you're
doing a good job!

Best,
Alistair

On 17 June 2017 at 00:22, Robert Elz <kre%munnari.oz.au@localhost> wrote:
> 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.
>
> While doing this, a couple of user visible changes just "snuck in"
> while I wasn't looking...
>
> Posix requires that '~' expand to he value of $HOME when HOME is set.
> We were doing that, except in the case where HOME="" where we left the ~
> in place instead of replacing it with the null string as required (the
> same was true for the even less likely case of ~user being found in the
> passwd file and having an empty home directory set there - we should be
> returning a null string in that case as well, and weren't, but now do.)
>
> If HOME is unset, then it is unspecified in POSIX what happens - we used
> to simply leave the ~, now I have made the shell return
>          getpwuid(getuid())->pw_home
> (assuming that exists of course).   This allows a script to compensate for
> being run with "env -i" (or similar) if it desires, which was more difficult
> before.   While many other shells retain our past behaviour (just leaving
> the '~') when HOME is unset, others do it the new way (this difference is
> why POSIX does not specify what must happen.)
>
> If anyone finds that this change causes problems, let me know, this was
> a trivial change, and would be easy to revert.
>
> There is also one additional fix to an obscure case of counting LINENO with
> "here documents" when a bizarre (and not working in many shells) end delimiter
> (containing newline characters) is used.   Never seen it in real life, so I
> doubt anyone will notice the difference (and this one was a bug fix.)
>
> kre
>