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

[Giles Lean <giles.lean%pobox.com@localhost>]

Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

[trim]

> 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.

[trim]

> 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.)

A reasonable argument.  (That I don't like it much doesn't mean it's
not a good argument. :-)

> What's needed now is some kind of decision, how NetBSD's shell should behave.
> Before that, more (informed) opinions would be useful.

I'm "informed" if working for several years for a Unix vendor including
time spent arguing standards conformance w.r.t. /bin/sh (and other
dellightful POSIX-isms) taught me anything.

I have also in the past had the miserable experience of having multiple
different shells (ksh springs to mind) *also* look at $ENV, but with a
different set of capabilities to /bin/sh, leading to all sorts of hoops
being jumped through in whatever file was referenced by $ENV to get the
Right Things to happen and more importantly no Wrong Things.

Also, I've read the PR, if that helps me be informed. :)

Finally, by chance, this morning is the morning I've been cleaning up
the mess on my OS X systems where /bin/sh is bash, and its slightly
peculiar ideas about startup files, what they do, and when they do it.

Herewth my recommendation, which all and sundry are welcome to ignore:

1. follow the standard precisely, but peferably make the change
   in a new release

2. if you need a shell that runs $ENV even when non-interactive,
   call it something other than /bin/sh

3. IMHO POSIXLY_CORRECT is too blunt an instrument, as it (as I recall)
   was somewhat snidely designed to get POSIX standard behaviour even
   when the standard was clearly broken.

   In this instance I don't think the standard is clearly broken.  It
   may not be optimal; but there have been a lot of shells that have
   operated in the way it specifies for a long time, which is why I
   presume that it was standardised that way.

My 2c.

Regards,

Giles

P.S. Of course if you want my *real* opinion, the POSIX committee was
having a very bad day when they settled on a ksh variant for /bin/sh.
But that's water under the bridge.