On 3/3/18 2:23 AM, Robert Elz wrote:
> Date: Fri, 2 Mar 2018 14:43:02 -0500
> From: Chet Ramey <chet.ra...@case.edu>
> Message-ID: <4502a0e5-0600-d294-9af2-4e9eeb0a0...@case.edu>
>
> 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 c...@case.edu http://tiswww.cwru.edu/~chet/
