Re: [PATCH] zsh/random module [UPDATED]

[Clinton Bunch <cdb_zsh@zentaur.org>]

On 11/20/2022 8:21 PM, Matthew Martin wrote:
> On Sun, Nov 20, 2022 at 07:59:54PM -0600, Clinton Bunch wrote:
>> On 11/20/2022 7:07 PM, Matthew Martin wrote:
>>> I'm not clear on where the getrandom builtin came from. I understand the
>>> desire for SRANDOM to have a proper random source in the shell; however,
>>> the rest seems like feature creep that if necessary could be implemented
>>> with a loop. It seems prudent to keep the initial module to a minimum to
>>> ensure there's a usecase and so backwards compat concerns don't crop up.
>>>
>>> Would it suffice for your uses to have a module with just SRANDOM?
>> One of my use cases is in precmd to replace this function
>>
>> get_random() {
>>    local retvar=$1;shift
>>    local max=${1:-32767}
>>
>>    local out=$(( int( rand48(my_seed) * $max + 0.5 ) ))
>>
>>    eval "${retvar}=$out"
>> }
>>
>> used here:
>>
>> precmd () {
>>    get_random cdb_fg "6"
>>    psvar[1]=$(( cdb_fg + 1))
>> }
>>
>> A better more uniform distribution of random numbers can be achieved with
>>
>> getrandom -U 6 -s cdb_fg
>>
>> than $SRANDOM % 7 which will have a modulo bias
> It's true SRANDOM % 7 would have modulo bias; however, even if only
> SRANDOM is provided, the out of range rejection loop could happen in
> shell code. While that's less convenient, I am of the opinion once
> a user needs to care about modulo bias, they're likely better served by
> a language other than shell.
Why write an external python script too generate a random password for a 
service account when you can do it with the shell you're already 
running, especially when python might not be available?
>
> If a uniform random function is desired in zsh, I think it should mirror
> the interface of arc4random_uniform: just take an upper_bound and return
> a value in the range [0, upper_bound).

The original implementation did exclude the upper bound, inadvertently, 
but after discussion it seemed that was counter-intuitive and something 
easily missed in a cursory glance at the documentation.  Adding a lower 
bound was easy enough and saves extra shell code even if it's not likely 
to be used as much.  I can see the first question from a user being why 
can't I specify the smallest number I want?  I'm already getting user 
complaints about a limit of 64 on count, even though that's unlikely to 
be exceeded in practice.  I'm also anticipating complaints about not 
generating negative numbers.

yes, much of getrandom *could* be implemented in shell code, much less 
efficiently.  For example my precmd could save the math eval by 
specifying getrandom -L 1 -U 7.

Once you've written the code to access the kernel random source, it 
seems to make sense to me to make its output as flexible as possible.  I 
don't get the concern about backwards compatibility in implementing a 
new builtin unless you know of an external command called getrandom that 
is in common use, and that's easily fixed by changing it to zgetrandom.

>