From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@sunsite.dk
Subject: Re: scope of variables in loops
Date: Sat, 21 Jun 2008 22:49:08 +0100 [thread overview]
Message-ID: <200806212149.m5LLn8Nx005122@pws-pc.ntlworld.com> (raw)
In-Reply-To: Message from "Joey Mingrone" <joey@mingrone.org> of "Sat, 21 Jun 2008 17:57:55 -0300." <f5b896260806211357r6d95026exf47a4a8ba68ec074@mail.gmail.com>
"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/
next prev parent reply other threads:[~2008-06-21 21:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <joey@mingrone.org>
2008-06-21 20:57 ` Joey Mingrone
2008-06-21 21:49 ` Peter Stephenson [this message]
2008-06-22 4:24 ` Bart Schaefer
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=200806212149.m5LLn8Nx005122@pws-pc.ntlworld.com \
--to=p.w.stephenson@ntlworld.com \
--cc=zsh-workers@sunsite.dk \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).