Bug? in 'integer' behaviour

Bug? in 'integer' behaviour

[Phil Pennock]

Hi.  I'm not subscribed, so please email me if there's anything else
you want to know (but I don't think anything is peculiar to my setup in
this one).  I'm using version 3.1.4 on Linux/x86.

In the distribution is Functions/randline which purports to show a
random line from a file.  The problem seems to be caused by a variable
declared integer not stripping off leading whitespace when assigned to.

randline:
 # get a random line from a file
 integer z=$(wc -l <"$1")
 sed -n $[RANDOM%z+1]p "$1"

This produces a divide by zero error, as 'z' is always zero.  Removing
the 'integer' keyword solves this, as does wrapping the RHS of the
assignment in $[...].

Is this unintuitively correct (features, gotta love 'em) or a bug?

Thanks.
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?

Re: Bug? in 'integer' behaviour

[Peter Stephenson]

Phil Pennock wrote:
> In the distribution is Functions/randline which purports to show a
> random line from a file.  The problem seems to be caused by a variable
> declared integer not stripping off leading whitespace when assigned to.
> 
> randline:
>  # get a random line from a file
>  integer z=$(wc -l <"$1")
>  sed -n $[RANDOM%z+1]p "$1"
> 
> This produces a divide by zero error, as 'z' is always zero.  Removing
> the 'integer' keyword solves this, as does wrapping the RHS of the
> assignment in $[...].

I think it's the trailing characters after the number which are causing
the problem.  From wc you get something like
    128 .zshrc
and if you do

integer z="    128 .zshrc"

you get

zsh: bad math expression: illegal character: .

But I get that from the $[...] expression too.  I get the same
behaviour in ksh, except that there is an error message from the
$(...), so it looks standard.  As a workaround you could do:

integer z=${$(wc -l <"$1")%"$1"}

or in a more standard way

y=$(wc -l <"$1")
integer z=${y%"$1"}

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: Bug? in 'integer' behaviour

[Bart Schaefer]

On Oct 5,  9:47am, Peter Stephenson wrote:
} Subject: Re: Bug? in 'integer' behaviour
}
} Phil Pennock wrote:
} >  # get a random line from a file
} >  integer z=$(wc -l <"$1")
} >  sed -n $[RANDOM%z+1]p "$1"
} > 
} > This produces a divide by zero error, as 'z' is always zero.  Removing
} > the 'integer' keyword solves this, as does wrapping the RHS of the
} > assignment in $[...].
} 
} I think it's the trailing characters after the number which are causing
} the problem.  From wc you get something like
}     128 .zshrc

No, that can't be right.  Note that input is being redirected to wc, so
it doesn't produce the trailing file name.  See:

zagzig% set -vx
zagzig% . ./randline multicomp
. ./randline multicomp
+ . ./randline multicomp
# get a random line from a file
integer z=$(wc -l <$1)
+ wc -l
+ integer z= 73
sed -n $[RANDOM%z+1]p $1
./randline: division by zero [3]
zagzig% echo $z
echo $z
+ echo 0
0

It's possible that some wc implementations don't emit the leading space
when given only -l, but GNU wc does.  It's also possible that some past
version of zsh ignored the leading space when computing the integer value
of the string assigned to the variable (though both 3.0.5 and 3.1.4 give
zero); that function has been around for a VERY long time, and I don't
think any maintainer has ever bothered regression-testing those samples
when making a new release.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Bug? in 'integer' behaviour

[Peter Stephenson]

`integer z=$(wc -l <"$1")' gives $z = 0:

Bart wrote:
> } I think it's the trailing characters after the number which are causing
> } the problem.  From wc you get something like
> }     128 .zshrc
> 
> No, that can't be right.  Note that input is being redirected to wc, so
> it doesn't produce the trailing file name.

You're quite right, things like "<" aren't so obvious first thing on
Monday morning.  I looked a little further and here's what's
happening:

% showargs() { print -l $*; }
% showargs z=$(wc -l <~/.zshrc)
z=
168

Replace `showargs' by integer and you'll see that the first argument
is z=, so that z gets 0, then the $(...) substitution splits words on
the initial spaces, and the second argument is 168.  I haven't looked
to see what zsh thinks it's doing with `integer 168', but the
word-splitting here does seem to be standard Bourne/Korn shell
behaviour.

So the real workaround is

integer "z=$(wc -l <$1)"

or

integer z
z=$(wc -l <"$1")

It's a little confusing that the argument to an `integer' isn't
handled the same as a straight assignment, but I don't see a way
around.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy