Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #13792 > unrolled thread

Re: Unset array doesn't work

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Unset array doesn't work Chet Ramey <chet.ramey@case.edu> - 2018-03-02 14:43 -0500

#13792 — Re: Unset array doesn't work

On 2/28/18 2:00 PM, Robert Elz wrote:
>     Date:        Wed, 28 Feb 2018 10:27:23 -0500
>     From:        Chet Ramey <chet.ramey@case.edu>
>     Message-ID:  <ba594d01-b9c4-5cd8-9fa0-2f20fd1d2d07@case.edu>
> 
>   | These are two different cases -- same context vs. a previous context. Your
>   | example is not the same as the original poster's.
> 
> OK, though I am not sure why that should make a difference.

It does.


>   | The global var is left unchanged, and satisfies references to $var with v1.
> 
> The second clause of that is what is brain dead.   There should be a simple
> invariant in all shell contexts, which is
> 
> 	unset X
> 	Y=$X
> 
> assigns the null string to Y (except in the case where X is read only, which
> is not a case of concern here.)

Perhaps. But bash has never done this. Not from day one. That's 30 years.

> Always.
> 
> No (other) exceptions.
> 
> None.

Never done it that way. Ever. Not once. (We can do this all day. But levity
aside.)

> 
> Similarly the expression ${X-unset} should always produce "unset" if X
> has been unset and not subsequently given a value.
> 
> Whatever else is believed about how variables should work, that part should
> remain true - if we cannot rely upon unset working to create an unset variable,
> then we're lost.

This is how bash dynamic scoping works. The exception for the declaration/
unset at the current scope was added 16 years ago, and the existing
behavior was already entrenched.


>   | You can mark any local instances in previous
>   | scopes (or the nearest previous scope that has a local instance of
>   | that variable) with a special `unset' attribute that will cause
>   | references to it to behave as if it were unset, leaving the global
>   | value unchanged. 
> 
> Yes.   That's the correct way I believe.

I can see doing this and allowing it to be toggled by a shell option.

> Lastly, where does the notion of "remove" come from?

As a way to describe the historical bash behavior, it works.  An instance
of a variable with a given name at a previous scope is removed, and another
instance of that variable at another scope is revealed.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web