Re: When should /bin/sh process ${ENV}

[christos%astron.com@localhost (Christos Zoulas)]

In article <16213.1266950529%epsilon.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>Bernd Ernesti <netbsd%lists.veego.de@localhost> said:
>  |  It would be nice to have a summary on tech-userlevel%NetBSD.org@localhost 
> and not in
>  |  a pr.
>
>The subject was PR [standards/42828] and anyone who wants the full discussion,
>so far, and as much as it is, can find it all in that PR (which was filed
>by Richard Hansen <rhansen%bbn.com@localhost>)
>
>The substance of the PR was that NetBSD's /bin/sh runs ${ENV} for
>all shells that start, whereas POSIX demands that it be run only
>for interactive shells.
>
>This isn't a bug in /bin/sh - what it is doing is exactly what
>sh(1) says it will do.
>
>The question is whether sh should be changed to comply with POSIX,
>or whether it should remain as it is currently documented (for future
>versions of NetBSD - there's no longer any thought of changing this in
>any NetBSD 5 update).
>
>Richard's primary motivation is (if I paraphrase correctly) that users
>who are expecting a POSIX environment might have a ${ENV} that runs a
>shell script, and if they do that they quickly get a fork bomb, as every
>shell started runs ${ENV} again, ...
>
>My argument is (basically) that it is trivial to simulate the POSIX rule
>inside ${ENV} (sh(1) tells you exactly how to do it, though without
>mentioning POSIX), but if the POSIX method is invoked, there's no way to
>get back to the NetBSD behaviour of having ${ENV} run for every shell
>(short of inventing a new environ var and making that serve this function
>of course ... and even that isn't truly safe, as whatever name we invent,
>someone might be using it for some other purpose, and then be surprised.)
>
>Anyone who wants the complete rundown on the pro & con arguments should go
>look in PR 42828.
>
>What's needed now is some kind of decision, how NetBSD's shell should behave.
>Before that, more (informed) opinions would be useful.

Oh head it behaves as Richard wants when POSIXLY_CORRECT is set in the 
environment before /sib/sh startup.

christos