I agree this could use some clarifying. 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; the same as if a name
is $name referenced, unqualified by a test operator, without previous
assignment. Then its appearance in subshell environments would be consistent
with the parents local state. As an operand it wouldn't need a trailing '=' to
distinguish it from a command name, and would be a shorter form of
name=<SQ><SQ> to get the same effect, or name=<SPC or NL> even. The script
would then have to explicitly unset name afterwards to undo the null
assignment, however.
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. Because the above
isn't explicit, the use case, as freebsd is treating it, where a script expects
IFS to be unset and stay unset, so the default <SPC><TAB><NL> is assumed, and
all utilities referenced to have IFS set to the null string upon invoke, if
these are similarly sensitive, is valid also.
It's also possible to read it that setting the attribute applies only when name
is previously set or thSo, something differentiating the three needs to be
added, it appears.
A synopsis line of:
export name[=[word]]...
I see as more requiring how freebsd is construing it, that if you want it to be
set locally the '=' is required, and then like with assignments if no word
follows it is treated as a null string. I'd still want some text explaining why
the 2 [ ] pairs, though.
On Sunday, July 7, 2019 Martijn Dekker <mart...@inlv.org> wrote:
On FreeBSD sh, when you set the export attribute on an otherwise unset
variable, an empty environment variable is exported, though the variable
continues to be considered unset within the current shell. This is the
only shell I know of that does this.
$ unset -v foo
$ export foo
$ echo ${foo+set}
[empty line]
$ sh -c 'echo ${foo+set}'
set
$ set | grep ^foo=
$ env | grep ^foo=
foo=
Question: is this behaviour a bug in POSIX terms?
As far as I can tell, the POSIX spec doesn't explicitly say what to do
in this case:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_22
| The shell shall give the export attribute to the variables
| corresponding to the specified names, which shall cause them to be in
| the environment of subsequently executed commands.
I could see how this phrasing technically requires the FreeBSD sh
behaviour, but given that no other shell does this, it seems unlikely
this requirement is intended. Could the text do with clarifying this?
Thanks,
- M.
--
modernish -- harness the shell
https://github.com/modernish/modernish
