I have just committed the changes that allow parameter expansion on $ENV
before processing (as required by POSIX) - it will make no difference to most
people who have ENV set to a simple filename (if there are no $'s in the value
of ENV (and no backticks) then it is used just like before. We also get (for
free, it just happens) arithmetic expansion (not required by POSIX) which,
if you wanted, would allow stuff like
ENV='${HOME}/.shrc.$(( (START_TIME % 86400) / 3600))'
to have a different startup file every hour ($HOME/.shrc.N where in thiis
example, N is the hour of the day, UTC - appropriate adjustments to the
arithmetic would allow a different timezone).
There is no ~ expansion however, either use $HOME or do the expansion
on setting ENV rather than when it is used.
Now for a question - a possible change.... Until now, if $ENV is not a full
pathname it is referenced relative to $PWD (the same as any other file).
I am not sure it is a great idea to have that happen by default - POSIX says
it is unspecified what happens when $ENV is not a fully qualified path name.
I'm considering, if it seems reasonable to those here, to change sh so it does
not read profile files (any of them) from relative paths (simply ignore any
such attempt). We couldn't do that before, as if there was an actual need for
current directory startup scripts, there would have been no method to achieve
it, but now if that is needed
ENV='${PWD}/.shrc'
(or whatever filename you want) will do that.
If this changes, then the read of ".profile" (which is also a relative path)
would change to '${HOME}/.profile' (with that processed after /etc/profile
has had a chance to change things, just like now).
This is all for HEAD (and NetBSD 9 when it is ready), there is no plan to
pull any of these changes up to any earlier release.
Opinions?
kre
