On 11/20/2022 8:21 PM, Matthew Martin wrote:
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?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 biasIt'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.
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.