X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Subject: Re: Some small bash issues
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1020214172635.1382B-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020214172635 DOT 1382B-100000 AT is>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.2 
Date: 14 Feb 2002 17:08:20 +0100
Message-Id: <1013702903.28939.111.camel@bender.falconsoft.be>
Mime-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 2002-02-14 at 16:29, Eli Zaretskii wrote:
> 
> On 14 Feb 2002, Tim Van Holder wrote:
> 
> > [tim AT bender] /home/tim>cat >fooscript <<\EOF
> > More>#! /bin/sh
> > More>echo $foo
> > More>EOF
> > [tim AT bender] /home/tim>foo=bar ./fooscript 
> > bar
> > [tim AT bender] /home/tim>echo $foo
> > 
> > [tim AT bender] /home/tim>cat >fooscript <<\EOF
> > More>#! /usr/bin/perl5
> > More>print $ENV{"foo"} . "\n";
> > More>EOF
> > [tim AT bender] /home/tim>foo=bar ./fooscript 
> > bar
> > [tim AT bender] /home/tim>foo=bar perl -e 'print $ENV{"foo"} . "\n";'
> > bar
> > [tim AT bender] /home/tim>echo $foo
> > 
> > [tim AT bender] /home/tim>foo=bar perl -e 'print $ENV{"foo"} . "\n";'
> > bar
> > 
> > So running perl DOES set foo; running echo doesn't.
> 
> Yes, but that's a different issue, I think: what I was talking about is 
> whether foo=bar is in effect for the duration of the single command after 
> "foo=bar".

Nope, we're on the same page; all the examples above are single commands
after foo=bar; and only in the case of 'echo $foo' is $foo empty.  With
our bash, it is apparently NEVER available.
The "echo $foo"s are simply there to ensure foo didn't get set by
mistake (as that would obviously invalidate the tests).

> You are talking, so it seems, about whether foo=bar stays in 
> effect _after_ that command exits.  I don't expect the latter to happen 
> in a shell, ...

I was merely remarking that when I tried 'foo=bar echo$foo' in ksh, not
bash, that foo remained set (so running 'foo=bar echo$foo' again printed
'bar', as did a plain echo $foo).
Maybe it's just that ksh auto-exports variables.