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: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: standards/42828: Almquist shell always evaluates the contents of 
${ENV} even if non-interactive
Date: Thu, 18 Feb 2010 05:36:43 +0700

 Note that this change makes sh fail to live up to its documentation ...
 
      If the environment variable ENV is set on entry to a shell, or is set in
      the .profile of a login shell, the shell next reads commands from the
      file named in ENV.  Therefore, a user should place commands that are to
      be executed only at login time in the .profile file, and commands that
      are executed for every shell inside the ENV file.  To set the ENV vari-
      able to some file, place the following line in your .profile of your home
      directory
 
            ENV=$HOME/.shinit; export ENV
 
      substituting for ``.shinit'' any filename you wish.  Since the ENV file
      is read for every invocation of the shell, including shell scripts and
      non-interactive shells, the following paradigm is useful for restricting
      commands in the ENV file to interactive invocations.  Place commands
      within the ``case'' and ``esac'' below (these commands are described
      later):
 
            case $- in *i*)
                  # commands for interactive use only
                  ...
            esac
 
 
 In particular, with this being a significant change, it is definitely
 not suitable for a pullup to NetBSD 5 (or any existing released system).
 
 Further, this is a case where sanity ought to win over standards, there's
 lots of stuff where our shell isn't the same as wha POSIX says it should
 be, some of considerably more importance than this one.
 
 It is trivial (as the doc says) to make the script be a no-op in
 non-interactive shells, if that's what's needed.   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.
 
 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, the script
 needs to be aware of why it will be invoked, and in what possible
 environments, and do sane things (for which, running other shell scripts,
 without resetting ENV first, is not included).
 
 I'd put this pack the way it was.   Screw POSIX in this case.
 
 kre