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 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  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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html