Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cuae2!ihnp4!mb2c!zeta!gamma!ulysses!sfmag!sfsup!dcm From: dcm@sfsup.UUCP Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: Lost Assignment of var in shell for loop with stdout redirection Message-ID: <1090@sfsup.UUCP> Date: Thu, 5-Feb-87 23:05:30 EST Article-I.D.: sfsup.1090 Posted: Thu Feb 5 23:05:30 1987 Date-Received: Sun, 8-Feb-87 01:27:41 EST References: <354@rlgvax.UUCP> Reply-To: dcm@sfsup.UUCP (David C. Miller, consultant) Organization: AT&T Information Systems, Summit, N. J. Lines: 47 Xref: watmath comp.unix.wizards:862 comp.unix.questions:948 In article <354@rlgvax.UUCP> dennis@rlgvax.UUCP writes: >While writing a shell script, I found an unexpected behavior >that I thought I would share with the net. > >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? > >-- >FullName: Dennis Bednar >UUCP: {seismo|sundc}!rlgvax!dennis >USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 >Telephone: +1 703 648 3300 Yes, this is a know shell bug. It also occurs with a structure like this: while read var do # anything done < /tmp/tmpfile If you happen to have ksh, I'd suggest using that, since this bug has been fixed there. Ksh doesn't spawn a new shell to do the redirection. Anybody have diffs to fix /bin/sh to work this way? Dave -- David C. Miller, consultant Communications Interface Addresses: Paperware: AT&T Information Systems, 190 River Road, Summit, NJ 07901 Liveware: (201) 522-6107 Software: {allegra,burl,cbosgd,clyde,ihnp4,ulysses}!sfsup!dcm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On good days life is T.A.N.S.T.A.A.F.L. On days like today: T.A.N.S.T.A.A.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~