Date: Sun, 7 Jul 2019 16:55:37 +0000 (UTC)
From: Shware Systems <[email protected]>
Message-ID: <[email protected]>
| I agree this could use some clarifying.
I agree with this much of your reply.
| Some may construe the synopsis that since name may be set directly
| with the =word portion, without this it is supposed to be set to a
| null string and not stay unset;
I don't think anyone is likely to do that, that is not what Martijn
suggested was wrong, nor what the example of what the FreeBSD sh
used to do showed, and I think irrelevant and just confusing things.
| Then its appearance in subshell environments would be
subshell environments have nothing to do with it either. It was
"exported to other commands" (that one of the examples given happened
to have the command be "sh" is largely irrelevant - sh is simply one
command which makes it easy to see what was in the environment passed
to it - most commands never expose that unless the variable name happens
to be one they particularly pay attention to).
| As an operand it wouldn't need a trailing '=' to distinguish it from
| a command name,
I cannot even begin to guess at the relevance or meaning of that.
| The script would then have to explicitly unset name afterwards
| to undo the null assignment, however.
If the name were unset afterwards, not only would the effect of the
null assignment (if there was one, which there isn't, and no-one has
ever believed there was) be undone, but the exportability of the name
(the thing that "export foo" is supposed to achieve) would be undone
as well.
| The shell is sensitive to behaving one way when some variables,
| IFS in particular, are unset, set to a null string, or is non-null.
The shell yes, but any script can be for any variable. But that's not
relevant really as it is not the issue.
| It's also possible to read it that setting the attribute applies only
| when name is previously set or th =word portion is included,
No it isn't. Though this one I'd grant is a slightly more likely
mis-reading, or perhaps just shell implementation bug, than your earlier
guess. But this also is not what Martijn was referring to.
| So, something differentiating the three needs to be added, it appears.
You have the problem all mixed up. No-one is doubting the effect of the
export command upon the shell itself.
What is in question is what should actually be placed in the environment
when an unset, but exported, variable exists in the shell, and some other
command is invoked. The current wording suggests that perhaps such a
variable should be added to the environment of other commands (which is
what the FreeBSD shell was doing) but we all know that any unset variable
really does not exist, and for all purposes should be treated the same
as any other variable that does not exist (IFS being a somewhat special
case, but but in a peculiar way - it isn't that the variable is treated
differently, ${IFS} behaves the same as any other variable, it is just when
the shell needs a value to use internally, other than for expanding ${IFS},
and IFS is unset, it uses IFS's default value instead of the null string
which is the normal reault of accessing an unset variable without the "-u"
option being set).
What needs to change is to perhaps add "if set" into the "shall cause them
to be exported of" words, making
which shall cause them to be, if set, in the environment of
subsequently executed commands.
kre
