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

["Greg A. Woods" <woods%planix.ca@localhost>]

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

From: "Greg A. Woods" <woods%planix.ca@localhost>
To: NetBSD GNATS <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: Wed, 30 Jan 2019 14:05:43 -0800

 --pgp-sign-Multipart_Wed_Jan_30_14:05:16_2019-1
 Content-Type: text/plain; charset=US-ASCII
 
 Perhaps we can change the subject of this PR, and the intent, to:
 
 	Please suppress all possible error messages that might arise
 	from the $ENV expansion and use by /bin/sh at startup
 
 At Wed, 30 Jan 2019 12:10:01 +0000 (UTC), Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
 >
 > [[....]]
 >  Not if it was a shell with arrays that I had implemented
 > [[....]]
 
 I guess you don't like Lua either?  :-)  (i.e. in addition to Ksh?)
 
 >  ps: bosh (which prides itself on being a true SysVR4 /bin/sh clone,
 >  with some more recent posix additions), dash, the FreeBSD sh, and ours,
 >  all give a "bad substitution" type error when asked to evaluate your
 >  $ENV expression, though that might not appear in all (or perhaps even
 >  any) when it is de-referenced at sh startup, either because they do not
 >  param expand $ENV (in which case they will be attempting to open a file
 >  of that name in $PWD) or by just suppressing the errors at that point.
 
 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,
 and you exclude all those that don't expand $ENV on non-interactive
 startup (bosh, for example, only uses $ENV on interactive startup, as,
 FYI, does Bash when invoked as "sh").  As an aside I'll note that
 expanding $ENV on non-interactive startup seems rather extremely rare in
 the shell-as-/bin/sh business -- in fact I can't find any other example
 where that happens other than systems where something very compatible
 with AT&T Ksh itself has been installed as /bin/sh (even OpenBSD long
 ago took away the expansion of $ENV on non-interactive shells for their
 ksh, which is also installed as /bin/sh).  This is of course no doubt
 due to the "when and only when an interactive shell is invoked" language
 in POSIX.  It is pretty strong language, for a standard; though I agree
 in principle with your original argument from PR42828.
 
 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
 and broken for anyone who uses Ksh or its many compatible derivatives
 (and expects who and uses traditional Ksh semantics and syntax for
 $ENV).  All the rest is bikeshedding (well, of course the security
 implications are important, but a somewhat different kind of issue
 entirely as they don't affect the fundamental usability of an isolated
 system per se).
 
 --
 						Greg A. Woods
 						Planix, Inc.
 
 <woods%planix.com@localhost>       +1 250 762-7675        http://www.planix.com/
 
 --pgp-sign-Multipart_Wed_Jan_30_14:05:16_2019-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Content-Description: OpenPGP Digital Signature
 
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCXFIfoAAKCRBmfXG3eL/0
 f43gAJ9I0oIPEGi84pJFbHMuVgq//wS71ACcCP+k0lI9eAjI3k8yk6BLIHK0BxI=
 =0qZg
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Wed_Jan_30_14:05:16_2019-1--