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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 19 Feb 2010 14:36:53 -0500
    From:        Richard Hansen <rhansen%bbn.com@localhost>
    Message-ID:  <4B7EE855.1050108%bbn.com@localhost>

  | My .profile sets ENV.  (By "script" I meant a file containing 
  | environment setup commands.

Ah, OK, fine (my .profile sets ENV as well...)

  | Why exclude user environments?  The purpose of ${ENV} is to customize 
  | the user's interactive shell.

Because it is a different degree of problem than I thought you were
suggesting.   With the use of $ENV that we're agreeing on, you get to
decide what's in it, and you know the environments where it will be used,
and you can read the doc for those environments and make sure that your
setup applies there.

Now that you know how NetBSD applies $ENV, I would assume that you have
no further problems - ie: for this usage, the difference from other systems
is a minor annoyance, not a serious impediment.

On the other hand, for "scripts" with the other (more common usage),
the author doesn't know all the environments where the script will be
used, and for that, it is far more important that anything that is
reasonably relying upon some standard behaviour gets what they're expecting.

If you had examples of the latter where NetBSD's application of $ENV
was a problem I'd be much more tempted to agree to a change, for the sake of
compatibility, for just user setup files, I'm not.

  | Would you be willing to take this up with the POSIX working group?

I don't have the time either ... and in any case, I've pretty much given
up on the current set of standards bodies - they've all become full of
people for whom the standard is what is most important, rather than the
systems that are built using the standard (ie: making the standard itself
seem better looks to me to be of greater importance than making the system
that uses the standard actually work better.)

  | Flawed implies that there are legitimate use cases that are not 
  | supported,

flawed just implies there is a defect - something that could be improved,
or which is less than perfect.

  | but I have not yet come across any such use cases.  Can you 
  | provide an example where a user needs ${ENV} evaluated upon invocation 
  | of every non-interactive shell?

"of every non-interactive shell" ?  No, of course not, but that's not
what is needed - the converse of "only used by non-interactive shells"
is "used by at least one non-interactive shell" (ie: the opposite of
"none" is "one" not "all").

And that's easy - I make scripts (personal use scripts) all the time
by simply cut and paste from my history - that is, whenever I detect that
I'm going to re-execute a set of commands that I have done in the not
too distant past, I assume that if I'm doing it twice, I'm going to be
doing it again, so I simply take what I did and stick it in a script, then
run the script.   That's a non-interactive shell running the script, and
in order to run correctly, it needs to run with the same environment that
my interactive shell where I first ran the commands had - that is, it
needs to have access to whatever is in ${ENV} because my interactive shell
had that access as well.

And yes, of course, I can ". ${ENV}" in the script, but then I need to
remember I have to add that, every time.

Another use, that is less common for me, but I have done on occasion,
is to define shell functions that replace standard commands, and either do 
something compatible, but in a different way (like turning "rm" into
a "mv" to a trash directory) or add trace/debugging to what is happening,
so allow debugging of complex sets of scripts to find out just where the
script is doing something it shouldn't be doing, and why.  For that, I
can set ENV so a suitable environment is established for the scripts that
I want to investigate - but only if they respect it.

  | Perhaps the flaw is in NetBSD's design:  The ${ENV} file can arbitrarily 
  | modify the shell execution environment (change the working directory, 
  | modify positional parameters, close file descriptors, trap signals, 
  | define functions, set shell options, etc.).  This means that shell 
  | script writers can't rely on a consistent initial environment.

Huh?   They can't rely upon most of that anyway - when the shell that starts
the script begins, the environment can be anything.   Of your list, about all
that can't be done is trapped signals, but signals can be ignored, which is
close enough to the same, and (I think) defined functions (or can they come 
from the environment?), which is one of the very things I want to be able to do.

Any of that that is important to the script needs to be explicitly either
tested, or set, in the script, to ensure the environment is as it expects.
Whether the change came from something done in $ENV, or was established
before the shell running the script began is largely irrelevant.

  | It is doubtful this would be a significant problem in practice, but in
  | theory this could lead to bugs that appear to be in a script file but are 
  | actually caused by the user's ${ENV} file.

Yes, of course it can.   If you put stuff in there that breaks things, you
get what you deserve (just the same as if you put commands in directories early
in your PATH with standard names but which don't do what the standard commands
with the same names do).    You're entitled to break things if you want to.
So is any other user.

  | but only if the 
  | community respectfully deals with legitimate user complaints.

I agree, but you need to understand that there's more than one way to
deal with a problem - simply making every change everyone asks for,
regardless of whether that change makes things better or not would
hardly be a responsible attitude, would it?   Nor does it mean that
whatever POSIX says is necessarily correct for us.

I don't think there's been anyone here who has been antagonistic, just
not agreeing with what you're asking - there is a difference.

Lastly, you're mostly just hearing from me, and I do not represent NetBSD,
I'm just offering an opinion - what will actually happens in NetBSD will
end up being decided by someone else.

kre