Mark Wheeler wrote:
> 'PIPE ... | TAKE' random(6,8) '| ...'
That will skew the distribution towards the shorter passwords. To
distribute them more evenly, allow a blank in the last positions with
the same likelihood as any character:
(end \) random 36
| take 6
| f: fanin
| not chop 3
| join *
| change x36 ,,
| x: xlate
| ...
\ random 37
| take 2
| f:
\ strliteral ,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
| x:
To generate a stream of them, you can use GATHER instead of TAKE|FANIN,
and then you can even out the distribution better by discarding some:
(end \) literal 11111122
| dup *
| fblock 1
| g: gather streamid
| not chop 3
| join 7
| change x3636 ,,
| pick 7 ¬== x36
| chop x36
| x: xlate
| ...
\ random 36
| g:
\ random 37
| g:
\ strliteral ,0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
| x:
Then use GATHER, SPECS, SYNCH, or whatever to match them up with your
input file of userids.
Something does seem screwy with the output of RANDOM in my trials of
this, though. I tried it with 3 and 4 in place of 36 and 37, and in
each trial there were several sequences I never got out of RANDOM 4.
In one it was 02, 11, 20, and 33; in the next it was 00, 13, and 22
(and I'd guess from the pattern 31, but I discarded those). If I use
any other byte of the output, though (multiplying the moduli by a power
of 256), the distributions look fine. So in the above you can change:
| g: gather streamid
| not chop 3
...
\ random 36
| g:
\ random 37
| g:
to:
| g: gather streamid
| specs 3 1
...
\ random 9216
| g:
\ random 9472
| g:
¬R
