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:

            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

            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
            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:

        echo $FOO
        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.


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

Reply via email to