Re: [BUG] Can't mark unset variables as read-only

[Bart Schaefer <schaefer@brasslantern.com>]

On Apr 29, 11:33am, Chet Ramey wrote:
} Subject: Re: [BUG] Can't mark unset variables as read-only
}
} > On Wed, 29 Apr 2015 06:55:56 -0700
} > Bart Schaefer <schaefer@brasslantern.com> wrote:
} > 
} >> On Apr 29, 11:36am, Peter Stephenson wrote:
} >> }
} >> } +Note that in zsh (unlike other shells) it is still possible
} >> } +to create a local variable of the same name as this is considered a
} >> } +different variable (though this variable, too, can be marked readonly).
} >>
} >> Hrm, I wonder if that, combined with "typeset" automatically creating
} >> locals when called in a function context (also a POSIX incompatibility?) 
} 
} It's not a Posix incompatibility; Posix does not specify typeset or local
} variables at all.  The Posix-conformant ways of declaring variables in a
} function result in global variables, as Posix specifies.

Thanks for refreshing my memory there.
 
} >> defeats the whole purpose of an unset readonly?
} 
} The question is whether or not you can use local variables to `shadow'
} readonly variables in a previous scope.  Bash doesn't allow you to do
} that.

This discussion has reminded me another thing I forgot:  for variables
that have defined meaning to the shell ("special" variables) zsh allows
shadowing of a readonly special only if the "-h" (hide) flag is passed
to "local" or one of its equivalents (integer, declare, etc.).

} If the purpose of readonly is to make a particular name/value pair
} immutable, I think that allowing a local variable to shadow it,
} especially if you're going to export that local variable, is a bad thing.

Here's a curious data point:  In ksh, functions declared with POSIX
syntax "name() { ...; }" treat readonly from the surrounding scope the
way bash does.  Those declared "function name { ...; }" treat readonly
the way zsh does, allowing shadowing in the local scope.

Maybe zsh needs yet another POSIX_* option.