scope of variables in loops

scope of variables in loops

[Joey Mingrone]

Hello,

Unlike bash, parameters that are set in loops on the command line
stick around.  It's not a big deal once you figure out what's going
on, but the code below can cause some head-scratching.  Is this
intended?  Is it controllable (is there a way to turn it off)?

Thanks,

Joey

zsh 4.3.6 (i386-portbld-freebsd7.0)% for ((x=0; x<=10; x++)) do echo "$x"; done
0
1
2
3
4
5
6
7
8
9
10

zsh 4.3.6 (i386-portbld-freebsd7.0)% for y in `ls *`; do echo $y; done
.Xauthority
.Xmodmap
.aspell.en.prepl
...
...

zsh 4.3.6 (i386-portbld-freebsd7.0)% for x in `ls *`; do echo $x; done
zsh: bad floating point constant

zsh 4.3.6 (i386-portbld-freebsd7.0)% unset x

zsh 4.3.6 (i386-portbld-freebsd7.0)% for x in `ls *`; do echo $x; done
0
1
2
3
4
5
6
7
8
9
10

Re: scope of variables in loops

[Peter Stephenson]

"Joey Mingrone" wrote:
> Unlike bash, parameters that are set in loops on the command line
> stick around.  It's not a big deal once you figure out what's going
> on, but the code below can cause some head-scratching.  Is this
> intended?  Is it controllable (is there a way to turn it off)?
>
> zsh 4.3.6 (i386-portbld-freebsd7.0)% for ((x=0; x<=10; x++)) do echo "$x"; do
...
> zsh 4.3.6 (i386-portbld-freebsd7.0)% for x in `ls *`; do echo $x; done
> zsh: bad floating point constant

There's nothing to turn off, as such, but as you say it does cause
head-scratching.

If you haven't declared a variable, and its first use is in a
mathematical context, then it's implicitly type, in this case as an
integer, as if you'd typed "integer x" before the first loop.  (Yes,
even despite the message about the bad floating point constant: that's
probably because it encountered a dot when looking at what it thought
was a formula, even before it tried to turn the formula into an
integer.)  So when you try to use it as a scalar the shell tells you
about it.

You can avoid this by explicitly typing the x as a scalar with "typeset
x" before the first use.  If it's become an integer you can use "typeset
+i x": that's a better bet than just unsetting it, because it means it
won't implicitly become an integer again.  It'll still be able to hold
integers, except it'll hold them as the string you see rather than in
the internal integer format.

By the way, you should write "for x in *", not "for x in `ls *`", unless
you're really relying on obscure effects such as getting names of
directories with a trailing colon together with the directory contents
or having the file names split on spaces.  (Presumably you're not
expecting such problems but it's a good habit to get into anyway.)
There are probably better ways of getting any special effects in zsh,
too.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: scope of variables in loops

[Bart Schaefer]

On Jun 21,  5:57pm, Joey Mingrone wrote:
}
} Unlike bash, parameters that are set in loops on the command line
} stick around.

Peter's answer is nearly comprehensive, but I did want to point out
that "unlike bash" is incorrect here.

schaefer[503] bash
[schaefer@torch ~]$ for ((x=0; x<=10; x++)) do echo "$x"; done
0
1
2
3
4
5
6
7
8
9
10
[schaefer@torch ~]$ echo $x
11


The difference is not whether the *variable* "sticks around" but that the
implicit integer typedef sticks.