Re: bin/53919: Please suppress all possible error messages that might arise from the $ENV expansion and use by /bin/sh at startup

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

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/53919: Please suppress all possible error messages that might arise from the $ENV expansion and use by /bin/sh at startup
Date: Thu, 31 Jan 2019 18:02:53 +0700

     Date:        Wed, 30 Jan 2019 22:10:00 +0000 (UTC)
     From:        "Greg A. Woods" <woods%planix.ca@localhost>
     Message-ID:  <20190130221000.DC6347A1F7%mollari.NetBSD.org@localhost>
 
   |  Perhaps we can change the subject of this PR, and the intent, to:
 
 I doubt a Subject: change is really needed, and the intent has
 obviously already changed.
 
   |  I guess you don't like Lua either?  :-)
 
 Actually, no idea, I have never taken the time to look at it
 (for no other reason than that.)
 
   | (i.e. in addition to Ksh?)
 
 Bourne's sh was a masterpiece of design, and given the constraints
 of making it work on a PDP-11, not a bad implementation either (though
 we are still suffering the after effects of some of what those
 limitations caused.)
 
 Korn's additions are mostly (not all) crap (design).
 
   |  Well, the part from "though" onward is kind of exactly my point,
   |  especially if you include the /bin/sh in all NetBSD releases to date,
 
 Which did not expand ENV - even though it was supposed to according to
 POSIX.
 
   |  and you exclude all those that don't expand $ENV on non-interactive
   |  startup (bosh, for example, only uses $ENV on interactive startup,
 
 For your usage that should really make no difference, the error just
 occurs more frequently.   If you were to somehow guarantee that you'd
 never start an interactive /bin/sh then I guess that might be more
 recevant, but I am not sure how you could do that.
 
 Further, the whole point of your ENV hack is because non-interactive
 shells expand $ENV and run the script, the idea is to suppress that.
 Doing it using non-standard mechanisms is bound to lead to more
 problems later, on some system, with some other shell.
 
   |  Anyways, the appearance of unwanted output (on either stdout or stderr)
   |  during the expansion and use of $ENV (i.e. the automated use, during
   |  startup) is what actually makes NetBSD-current /bin/sh entirely unusable
 
 I have (locally) made changes that avoid the errors.   They seem to
 work...   If no-one objects, I will commit those sometime soon.  (It
 is not a complex change).
 
 kre