Re: Re-establishing the "magic" of the special vars in sh(1)

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

    Date:        Sat, 9 Feb 2019 13:08:15 -0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <q3mjbv$8v0$1%serpens.de@localhost>

  | Doesn't POSIX require that the variable is non-magic once set or unset
  | for the lifetime of the shell?

POSIX has only LINENO that is like this, and is very wishy-washy
about what happens:  [XCU 2.5.3]

	If the user unsets or resets LINENO, the variable may
	lose its special meaning for the life of the shell.

Just "may".   It is not even "unspecified".

  | N.B. that would also be my preferred handling of all such variables.

For LINENO we could make behave like that trivially easily - I have
not because of some tricks that are useful when making it local,
because of its unclear (and hence two different meanings) definition
in functions - both of which we support.   And because no-one ever
wants to use LINENO any other way.

For RANDOM we cannot, as we need the ability to set the seed.

All others (now, not as initially implemented) do behave that way - and
I agree, that is correct when the script explicitly sets (or unsets) them.

The issue of more concern here is for a script that wants to use
(e..g. LINENO, if we change it) - eg: an autoconf script, and where
someone has exported it into the environment (as in:
	export LINENO
which when I was adding the code to make it work correctly, I did
a lot as part of testing how it was working).   If that has happened,
no descendent script would ever be able to use LINENO in its intended way,
unless an intervening script has unset it (so the lower script stats
without LINENO in the environment.)

That I think is broken.   For LINENO we could fix it by having the
environment value ignored ... based upon the same assumption as above,
that no-one ever really wants to use it for other than how it is
defined to work (that's effectivelty what we do now, by making LINENO
be very special, rather than just ordinary special.)

For other vars though there is no such assumption, and passing a value
through the environment and expecting it to be available is an entirely
reasonable technique, which should work ... so we cannot simply (in general)
override the environment with the magic.

We need another way for the script to indicate that it wants the
magic variety of the variable - when it wants non-magic, all it needs
to do is use it in the normal way ... unless it is expecting a value
through the environ, first init it (so any environ value is overridden)
and then simply use it.    If a script is willing to take an arbitrary
value from the env (perhaps sanitising it, or not, as needed) then if
nothing was provided and the magic remains, no real harm is done.

kre

ps: POSIX also says, in XBD 8 ...

	It is unwise to conflict with certain variables that are
	frequently exported by widely used command interpreters and
	applications:

and lists a whole bunch, including RANDOM and SECONDS (which are two
that we implement and give magic status to) with which it is "unwise
to conflict" whatever that means (we implement several of the others
as well, IFS, PS1, HOME, PWD, but they're not magic, and can simply be
reset to a good value if found corrupted (or even just set) in the
environment - for some of them that is automatic in sh init.)   Since
this section is all about what is in the environment, it is also kind
of odd to believe that they expect that simply being present there is
a "conflict" - yet for most variables, it really needs to be.