bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unset does not act as expected on namerefs


From: Chet Ramey
Subject: Re: unset does not act as expected on namerefs
Date: Sat, 06 Jun 2015 12:38:43 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/1/15 9:59 PM, Shawn Wilson wrote:
> Top posting as I'm kinda going out of band of the thread here;
> 
> Having read the discussion, I guess the issue I brought up really
> isn't a "bug" (though Greg's points probably should be considered
> bugs). I'll preface this by saying I'm not an expert in bash by any
> means. However, most languages have a garbage collection facility
> which cleans up anonymous refs with nothing pointing to it and most
> high level languages make it easier to make a soft or symbolic
> reference than making hard references. But also, when you
> 'undef'/delete()/whatever the variable or the pointer, handle both
> and avoid this issue. While I do like the idea of pointers for bash
> variables, I would much prefer being able to create references.
> Also, whatever happens, I think there should also be a way to test
> for variable type (either another test flag or something like perl's
> ref() ).

I think it's a case of mismatched expectations.  There are a couple of
ways to go with this, and I went with the way Korn specified `unset'.
I initially implemented namerefs in bash without any special changes to
unset, but ended up adding it for compatibility.

Bash's dynamic scoping also drove some of the decisions.  Just as you
can follow the call chain to get different instances of a variable
named `x', for example, you get the same kind of variable resolution
with namerefs when you use `soft' symbolic references rather than `hard'
pointer references.  You absolutely have to be careful when you do this;
this part of the shell is a sharp instrument.  It's like I told Greg:
dynamic scoping is fundamental to how bash works, and namerefs don't
change that.

(Bash-4.3 has a way to test whether or not a variable is a nameref:
`test -R'.)

There's no need to flame anyone about this.  It's fair to discuss the
rationale for design decisions.

Chet
- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlVzIgoACgkQu1hp8GTqdKufHQCeL4Z0v8l9Au7hWJbr/lnT3NxI
SOsAn1gDxHDXkshb8mfRaANy8dFyhOlh
=bZx+
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]