Re: typeset -r prevents local variable of same name.

[Eric Blake]

On 02/17/2011 07:48 PM, Chet Ramey wrote:
> Consider a quick, contrived example: an administrator writes a shell
> package (library, set of functions, whatever) that includes, among
> other things, ways to make sure that some other package is invoked with
> a particular set of arguments and environment.  He does this in part by
> declaring some variables readonly.  Programs invoked by this package
> change their behavior depending on the value of environment variables,
> so it's important to the correct operation of this script that the
> variables don't change.  It should be harder to cirvumvent this, possibly
> creating a security hole, than just declaring a shell function with a
> local variable that then calls a public function that expects the variable
> to have some other value.

Ah, so we're back to the debate of static vs. dynamic scoping.  David
Korn is insistent that if POSIX standardizes typeset that only static
scoping be standardized, whereas bash currently only implements dynamic
scoping (but static scoping could be added on top of that, via
appropriate options to typeset).  Overriding statically scoped variables
is not a security risk, but overriding dynamically scoped variables is
asking for problems.  I agree with bash's current implementation
restrictions, given its current scoping rules.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature