Re: bin/55820: sh sources the ENV file for non interactive shells

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

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/55820: sh sources the ENV file for non interactive shells
Date: Tue, 24 Nov 2020 05:53:11 +0700

     Date:        Mon, 23 Nov 2020 18:40:00 +0000 (UTC)
     From:        aprogrammer188%gmail.com@localhost
     Message-ID:  <20201123184000.CAAB11A9241%mollari.NetBSD.org@localhost>
 
 
   | - the file designated by ENV is source for non-interactive shell,
   | it shouldn't according to POSIX
 
 This has been discussed (at length) before, see PR standards/42828
 We are not going to change it.
 
 If you prefer the POSIX behaviour, start the shell with the posix
 option turned on (either by -o posix on the command line, or with
 POSIXLY_CORRECT set in the environment that the shell inherits on startup).
 
 The more common way to deal with this is with something like
 
 	case "$-" in
 	*i*)
 		# interactive only startup commands go here
 		;;
 	esac
 
 The commands can be just ". some-other-file" if you want to keep the $ENV
 file short so it doesn't slow processing too much.
 
 
   | - when executing an "exit" command in that file, the shell exit;
 
 That is what it is supposed to do.
 
   | other shells I've tested just stop processing the file and continue
   | their normal execution.
 
 Then they are broken (not posix conformant).
 
   | I don't know if POSIX specify this behavior.
 
 It does.   For ENV it says (the current version)...
 
    resulting value shall be used as a pathname of a file containing shell
    commands to execute in the current environment.
 
 In the forthcoming version, to deal with some other issues (mostly relating
 to aliases) the text has been revised (expanded), but still says
 
    parse the tokens as a program (see Section 2.10), and execute the
    resulting commands in the current environment.
 
 That is, it is quite certain that ENV processing does not create a new
 execution environment (which is good, as if it did, commands like cd and
 umask. etc., in it would not behave as expected).
 
 About exit it says:
 
    The exit utility shall cause the shell to exit from its current
    execution environment [...]
 
 (what follows is about the status, and there is a whole lot about EXIT traps).
 
 Since while processing ENV the execution environment is the parent shell
 environment, and since exit causes that to terminate, the shell simply
 (after EXIT trap processing) terminates.
 
 Since there is nothing in this PR which is going to result in any
 changes, I will close it in a day or so.
 
 kre