From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Tadeusz Andrzej Kadłubowski" <yess@hell.org.pl>, git@vger.kernel.org
Subject: Re: [PATCH] Documentation: filter-branch env-filter example
Date: Thu, 14 Feb 2013 16:24:59 -0500 [thread overview]
Message-ID: <20130214212459.GA8005@sigill.intra.peff.net> (raw)
In-Reply-To: <20130214210910.GA6660@sigill.intra.peff.net>
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
next prev parent reply other threads:[~2013-02-14 21:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 19:34 [PATCH] Documentation: filter-branch env-filter example Tadeusz Andrzej Kadłubowski
2013-02-14 20:29 ` Junio C Hamano
2013-02-14 21:09 ` Jeff King
2013-02-14 21:24 ` Jeff King [this message]
2013-02-14 21:51 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2013-02-13 19:47 Tade
2013-02-14 6:49 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130214212459.GA8005@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=yess@hell.org.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).