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

[Richard Hansen <rhansen%bbn.com@localhost>]

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

From: Richard Hansen <rhansen%bbn.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: standards-manager%netbsd.org@localhost, gnats-admin%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: Thu, 18 Feb 2010 02:14:07 -0500

 Robert Elz wrote:
 > In particular, with this being a significant change, it is definitely 
 > not suitable for a pullup to NetBSD 5 (or any existing released system).
 
 Agreed.
 
 > On the other hand, 
 > if ${ENV} isn't run when *every* shell starts, what is?   If there's 
 > nothing, ten all that's left is what's in the environment to tailor 
 > the shell, and not everything can be done there, and even when it can, 
 > passing around all kinds of shell specific noise in the environment, to 
 > every process that runs, isn't a sane way of operating.
 
 I agree that the POSIX design is suboptimal, but at this point there is 
 greater value in being compatible than in being right.
 
 Cross-platform scripts can't rely on NetBSD's nonstandard behavior, so 
 they won't take advantage of it.  NetBSD-targeted scripts that require 
 the nonstandard behavior would be better served by an extension 
 specifically for that purpose (e.g., dot ~/.nbshrc upon every shell 
 invocation).
 
 It would be unfortunate if an ordinary script ran everywhere except NetBSD.
 
 > What's more, "ENV" is the name of the env var that sets the startup 
 > script for everthing that's a basically Bourne compatible shell (though 
 > that shell had no similar concept, of course) - but not all shells are 
 > the same,  and stuff that fits one shell won't fit.  The effect of this
 > is that it isn't sane to put just any random script as $ENV,
 
 These are arguments for standards compliance, not against.
 
 > I'd put this pack the way it was.   Screw POSIX in this case.
 
 I think it should be kept, just not pulled into netbsd-5* in order to 
 minimize surprises.  Fixing this bug might raise some issues, but I 
 believe the long-term benefit from standards compliance will outweigh 
 the short-term pain.
 
 -Richard