On Thu, Feb 14, 2013 at 04:09:10PM -0500, Jeff King wrote:
> I think the advice in the documentation about re-exporting is because
> some versions of the bourne shell will not reliably pass the new version
> of the variable when you do this:
>
> VAR=old
> export VAR
> VAR=new
> some_subprocess ;# we see $VAR=old here!
>
> I do not recall ever running across such a shell myself, but rather
> hearing about it third-hand in a portability guide somewhere.
The closest I could find in the autoconf shell guidelines[1] is that the
automagic export marking for incoming variables is not always accurate:
export
The builtin export dubs a shell variable environment
variable. Each update of exported variables corresponds to
an update of the environment variables. Conversely, each
environment variable received by the shell when it is
launched should be imported as a shell variable marked as
exported.
Alas, many shells, such as Solaris 2.5, IRIX 6.3, IRIX 5.2,
AIX 4.1.5, and Digital UNIX 4.0, forget to export the
environment variables they receive. As a result, two
variables coexist: the environment variable and the shell
variable. The following code demonstrates this failure:
#! /bin/sh
echo $FOO
FOO=bar
echo $FOO
exec /bin/sh $0
when run with `FOO=foo' in the environment, these shells
will print alternately `foo' and `bar', although it should
only print `foo' and then a sequence of `bar's.
Therefore you should export again each environment variable
that you update.
I don't know what the behavior would be on such shells of:
#!/bin/sh
echo $FOO
FOO=bar
export FOO
echo $FOO
exec /bin/sh $0
I.e., would the "export" correctly reconcile the local and environment
copies of the variable, or are they forever broken? I don't have such a
system to test on. But that would more closely match what we are doing.
-Peff
[1] https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html