Re: Bug? in 'integer' behaviour

["Bart Schaefer" <schaefer@brasslantern.com>]

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