Hello, According to jot(1)'s man page:
"$ jot -w %d -r 100000 1 4 | sort -n | uniq -c 33306 1 33473 2 33221 3 Note that with random sequences, all numbers generated will be smaller than the upper bound. The largest value generated will be a tiny bit smaller than the upper bound. For floating point formats, the value is rounded as described before being printed. For integer formats, the highest value printed will be one less than the requested upper bound, because the generated value will be truncated." The "smaller than the upper bound" part used to be correct but not anymore: $ uname -a OpenBSD something.somewhere 5.9 GENERIC#1561 i386 $ jot -w %d -r 100000 1 4 | sort -n | uniq -c 24729 1 25035 2 25106 3 25130 4 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. Cheers, Philippe
