Re: bin/53919: please revert changes that make /bin/sh evaluate $ENV non-interactively

["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 revert changes that make /bin/sh evaluate $ENV non-interactively
Date: Tue, 29 Jan 2019 10:51:27 -0800

 --pgp-sign-Multipart_Tue_Jan_29_10:51:10_2019-1
 Content-Type: text/plain; charset=US-ASCII
 
 At Tue, 29 Jan 2019 06:45:01 +0000 (UTC), Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
 Subject: Re: bin/53919: please revert changes that make /bin/sh evaluate $ENV non-interactively
 >
 >  Your usage has always been broken, it just has not affected you
 >  until now.
 
 Broken?  I think not.  It just hasn't ever interacted so horribly with
 NetBSD /bin/sh (or any other POSIX-ish system shell) ever before.  I've
 installed and used Ksh or something compatible enough on almost all of
 the extremely many and varied systems I've used since 1985, and I've
 used the same $ENV setting since before 1993, and I've never seen any
 other system shell misbehave when faced with any aspect of my Ksh
 environment.  It is though somehow pleasant to see a situation where the
 REPL of a system's /bin/sh isn't entirely useless to Ksh users (which of
 course has been more or less true of NetBSD's /bin/sh since 1.0).
 
 However I'd like to prevent any /bin/sh in any current or future NetBSD
 release from being the first to so misbehave.
 
 So, with a bit more debugging, I see that the fundamental reason NetBSD
 /bin/sh hasn't been a problem for Korn and Korn-like Shell users since
 growing its $ENV hack is that it has been silently failing to do
 anything with David Korn's long-recommended setting for $ENV.  Here's
 why, from ktrace+kdump:
 
  13571      1 sh       CALL  open(0x7f7ffffffb6d,0,0x7f7ffde06440)
  13571      1 sh       NAMI  "${ENVFILE[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}"
  13571      1 sh       RET   open -1 errno 2 No such file or directory
 
 However this failure is silent and un-obtrusive, and efficient.
 
 Now that I see this clearly in this context it makes perfect sense.
 
 So, the thing that made my new -current system entirely unusable was a
 new error message, and the most frustrating thing was the futility and
 uselessness of that feckless error message.
 
 One thing is certain:  The $ENV form using arrays is not going away.  It
 has worked for 30+ years, and is widely recommended, including in the
 "The Kornshell" book (since 1989).  This method has worked A-OK with
 _all_ Ksh derivatives I've ever encountered, including even Zsh (older
 Zsh, that is, IIRC -- newer Zsh is, if I'm not mistaken, even more Ksh
 compatible).  Even if I'm willing to change my own interactive shell
 settings, there's no changing the behaviour of shells that now prevail
 in the vast enormous majority of all other systems in the world.
 
 I'm rather sad that the POSIX committee was somehow able to justify, at
 least to to themselves, a half-baked appropriation of this ancient Ksh
 feature.  But that's water under the bridge.  (Perhaps I'm most sad that
 I personally wasn't able to be more involved in POSIX, but that's also
 flowed long ago into sea of time.)
 
 So I think I would be happy enough if /bin/sh guaranteed never to make a
 peep about $ENV expansion or open() failures in all normal circumstances.
 (i.e. maintain the status quo of behaviour in existing releases).
 
 Of course I would also be happy if there were some command-line flag
 that made the shell very noisy about $ENV issues.  Perhaps "-x" would
 suffice, though I see it is already quelled by read_profile(), so
 something stronger would probably be needed for profile and ENV file
 debugging.
 
 >  A better solution for your problem, which should be much more
 >  portable, is simply to make $ENV be a very short file, that determines
 >  whether it should be used at all (if you don't want it in non-interactive
 >  shells, it should simply return) and then determines which shell is
 >  being run [[...]]
 
 Sorry, I don't think that is a better solution at all.  It's a bad
 (inefficient) hack.  Change for the better is fine, but not change for
 the worse.
 
 The only good solution is to do something smart during the runtime
 expansion of $ENV to prevent the open from occurring or at least from
 succeeding, just as Korn suggested in the beginning.  I think I could
 come up with a new hack to be compatible with a no-arrays shell, but as
 I said, the arrays method simply isn't ever going away in wider circles.
 
 --
 					Greg A. Woods <gwoods%acm.org@localhost>
 
 +1 250 762-7675                           RoboHack <woods%robohack.ca@localhost>
 Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>
 
 --pgp-sign-Multipart_Tue_Jan_29_10:51:10_2019-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Content-Description: OpenPGP Digital Signature
 
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCXFCgpAAKCRBmfXG3eL/0
 f6ArAJ9R+NHJj6J9uIXJ9CCfOrxVYiu8JACeNF9WupOyGbVXT/raih9kMb88moo=
 =S8DS
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Tue_Jan_29_10:51:10_2019-1--