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

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

The following reply was made to PR standards/42828; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Richard Hansen <rhansen%bbn.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, standards-manager%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Subject: Re: standards/42828: Almquist shell always evaluates the contents of 
${ENV} even if non-interactive
Date: Sun, 21 Feb 2010 20:52:23 +0700

     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