Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!lll-lcc!styx!twg-ap!amdahl!pyramid!decwrl!decvax!tektronix!tekgen!tektools!jerryp
From: jerryp@tektools.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Lost Assignment of var in shell for loop with stdout redirection
Message-ID: <2171@tektools.TEK.COM>
Date: Fri, 6-Feb-87 12:53:40 EST
Article-I.D.: tektools.2171
Posted: Fri Feb  6 12:53:40 1987
Date-Received: Sun, 8-Feb-87 08:29:03 EST
References: <354@rlgvax.UUCP>
Reply-To: jerryp@tektools.TEK.COM (Jerry Peek)
Followup-To: comp.unix.questions
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 34

[I've restricted this followup to comp.unix.questions only.]

In article <354@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis Bednar) writes:
> In summary, apparently
> 
> for i
> do
> 	var=xxx
> done >/tmp/tmpfile
> 
> causes the shell interpreter to run a sub-shell, and so the value
> of $var set in the middle of a for loop is lost if $var is referenced
> after the for loop.  IS THIS CONSIDERED TO BE A sh(1) bug?

You're right about the loop: it runs in a sub-shell.
(This is true with the Berkeley Bourne shell, at least.)
The same thing happens with redirected input, as in:

	someprog |
	while read line
	do
		...set some shell variables...
	done

shell variables set inside the loop won't be available outside of it.
I think it's a well-known bug [anyone vote for calling it a feature? :-)]

It's fixed, at least partially, in the Korn Shell.

--Jerry Peek, Tektronix, Inc.
US Mail:      MS 74-900, P.O. Box 500, Beaverton, OR 97077
uucp-style:   {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp
Domain-style: jerryp@tektools.TEK.COM
Phone:        +1 503 627-1603