bug-bash
[Top][All Lists]
Advanced

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

Re: Unset array doesn't work


From: Chet Ramey
Subject: Re: Unset array doesn't work
Date: Sun, 4 Mar 2018 17:31:35 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 3/3/18 2:23 AM, Robert Elz wrote:
>     Date:        Fri, 2 Mar 2018 14:43:02 -0500
>     From:        Chet Ramey <address@hidden>
>     Message-ID:  <address@hidden>
> 
> My final comments on this subject:

Mine, too.

> 
>   | Perhaps. But bash has never done this. Not from day one. That's 30 years.
> 
> That a bug (be it a design bug, or a coding bug) has existed a long tiime
> does not make it any less a bug.
> 
> I have been using bash for essentially all that time (from before you took
> over maintainership) and I never knew it worked like that.   From comments
> here (where some people far more knowledgable about bash and its
> internals than I are to be found) I suspect that very few other people know
> about it either.

There are actually a number of large projects that depend on it, most
notably bash-completion. The `upvar' `package' also exploits the current
behavior.


>   | I can see doing this and allowing it to be toggled by a shell option.
> 
> A suggestion:   Do that for bash 5, and in the alpha release, make
> the option default to cause things to work the opposite way than
> happens now (so the option needs to be explicitly changed to get
> the current behaviour).  

No, I'm uninterested in the significant potential to just break
bash-completion. I haven't combed my way through all that code, but
I've been assured that it depends on the current behavior in some way.

I may turn this hypothetical new variable on myself and see what happens
with bash-completion on a system that has it installed.


> Yes, that I understand.   My issue is that I believe this is colouring
> your thoughts on just what "unset" is - same as the "appear/be"
> (trivial seeming) semantic issue you commented on in another message.
> 
> That is, it appears to me as if you believe that "unset" (as a state, not
> the command here) implies "non-existing".   That's never been correct.

OK, let's say a variable is an object with a name, attributes, and a value,
and that being `unset' means it does not have a value. That breaks down
fairly quickly:

        a=4
        export a
        unset a

        a=7
        printenv a

doesn't ever print `7'. The `unset' builtin has removed the variable: there
is no name, there are no attributes, and there is no value. The export
attribute was not retained when a variable with the same name was given a
new value.

It means you can create an object with two or more of the three, and
the variable will be `unset' (as a state) until it's been given a value,
but `unset' (the builtin) removes all three.

So the `unset' builtin removes a variable, at least at the global scope.
What that means in terms of a local variable is the question.

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



reply via email to

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