Re: IGNOREEOF and POSIXLY_CORRECT don't ignore invisible vars

[L. A. Walsh]

Chet Ramey wrote:
> Think it through.  A variable is not set until it has been assigned a
> value.  Giving a variable an attribute (in this case, the `local'
> attribute) without assigning a value means that the variable is still
> unset.  For example,
>   
====
Unless it was set in the global context outside of the function.
The local, it seems is sets the local attrib to any future references
of set/unset.  Otherwise, it seems you'd have the situation of
local Psx_Cor; unset Psx_Cor, where the "unset", counterintuitively,
would unset the global, and the "local Psx_Cor" would just be
ignored because it wasn't _set_ to a value. 

I.e. Suppose you want to ensure that Psx_Cor was "unset" for your
current context.  If you set it first, then bash goes through and
changes more than one behavior and bash setting (as in shopt/set -o),
then unsetting it wouldn't yield what you had in the first place.

I ran into this where I started a script with "turning off posix",
as I wanted various bash behaviors -- however, one of the behaviors
I had set manually, it turns out, was not part of the bash-base-set,
but part of the posix set.  The result was my explicit setting of
that bash-setting was "unset" by doing the set +o posix, even though
posix was already off. 

To minimize effects of options in 'shopt/set' being toggled, it seems
localizing Pos_Cor, and unsetting it should do the opposite of localizing
Pos_Cor and setting it.


> export X
> echo ${X:+set}
> printenv X
>
> will display nothing.  So the two examples Grisha gave print the same
> thing, though the documentation says that POSIXLY_CORRECT and IGNOREEOF
> have an effect only when set (though IGNOREEOF is more vague, and talks
> about `no value', by which it means the null string).
>
> Grisha's question is whether or not the variables need to be set before
> having side effects.  I tend to agree with him.
>   
----
   Then you need to keep track of shopt/set values set manually,
and not auto-adjust them to the posix-state, and then auto-adjust them
to some non-posix-state (which isn't necessarily the same state as the
pre-set version).  Of course you may have fixed all places where that
occurred -- and any manually set bashopts, that are set to posix values,
don't get unset -- though this may be still be happening in the case
of 'unset' already.  I.e. I'd prefer all the individual values in 'shopt'
and set-o, not be affected if one turns posix off when it was already off,
and vice-versa.

   In the case of local POS_COR;unset POS_COR, are you saying that
because POS_COR wasn't assigned a value, that the "unset" in the function
would unset the global value?   That seems rather counter-intuitive and
likely to cause more confusion, no?  If you set local on POS_COR, then
declare -x POS_COR, would it be affecting the local or the global copy?

   If you are going to do that, then bash should throw some warning or
error regarding an attempt to change state on a variable that has
been declared local but is still global because the local value has
not yet been set.

-l