Re: standards/42828 (Almquist shell always evaluates the contents of ${ENV} even if non-interactive)

[kre%NetBSD.org@localhost]

Synopsis: Almquist shell always evaluates the contents of ${ENV} even if non-interactive

State-Changed-From-To: open->closed
State-Changed-By: kre%NetBSD.org@localhost
State-Changed-When: Wed, 05 Dec 2018 08:21:06 +0000
State-Changed-Why:
It has been over 8 years now, and nothing else has changed, nor
(as best I can tell) have there been more complaints about the
NetBSD behaviour.

Unlike when the original discussion was held, I am now in a position
where I could change things, but I am no more inclined to now than
I was (would have been, if able) then.

The current situation is that $ENV is read by all sh startups,
interactive or not, unless the posix option is set - either by
"-o posix" or by having POSIXLY_CORRECT in the environment.

I also know more about the POSIX standards process now than I did
then, and am a bit less disenchanted with that group than some
others around - however from that I have also discovered that a
system is supposed to document what is needed for it to be POSIX
conformant, and that it is not simply to be assumed that any
random system will offer a posix conformant environment by
default.

That is, if you want posix conformance, you need to read the
system doc, and do whatever it says is required to obtain that.

In this case, for at least this issue, that is to include
POSIXLY_CORRECT in your environment (which can be done in
.profile).   That will not make the NetBSD shell conform
to POSIX, but it will in this particular case.

I was idly wondering whether there was anything else I could
do which would improve things, but I have concluded that there
is nothing which would not break backward compatibility that
would be any simpler than this.

There is no point keeping this PR open any longer, there does
not seem to be much chance of any more progress than that which
has already been made.

kre

ps: on the other hand, the companion PR (42829) which requests
parameter expansion on $ENV is likely to see some action soon.
I see no particularly good reason that one should not be handled.
The NetBSD shell finally has the internal mechanisms to allow
that to be done without a lot (more) messing around.