On Thu, Jul 14, 2016 at 08:42:55PM -0400, Ted Unangst wrote:
> Philippe Meunier wrote:
> > Looking at the cvs log for jot.c, this seems to be a known change:
> >
> > "revision 1.27 [...] Internally, jot -r now uses arc4random_uniform()
> > whenever this is clearly possible. In particular `jot -r 1 10 20'
> > yields an unbiased random number between 10 and 20 (both ends
> > inclusive) from the shell."
> >
> > I only discovered this change today after noticing that one of my
> > shell scripts that used to work fine had started to fail with a low
> > probability: the script uses jot(1) to generate a sequence of random
> > array indexes, and with this change an index can now be out of bounds
> > with a probability of about 1/1700. Fortunately it isn't an important
> > script but given the low probability of failure it wasn't exactly fun
> > to debug. Anyway, I don't know which one of jot or jot's man page is
> > going to be fixed but I'd advocate for reverting to the previous
> > behavior to preserve the semantics of scripts that rely on it.
>
> The current behavior seems far better (though I realize it's different.) I
> have difficulty understanding what the man page is trying to say. Something
> about expect the unexpected I think. I'd much rather delete all that nonsense.
IMO, the changes have been done without much care, breaking what's documented.
There are thee examples using -r in the man pages. 2 of them are now broken.
The second exmaple:
$ jot -r -p 0 100000 0.5 3.5 | sort -n | uniq -c
25120 0
49882 2
24998 4
So I'd says there are real bugs introduced with the latest commit.
-Otto