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

[Clinton Bunch <cdb_zsh@xxxxxxxxxxx>]

On 11/20/2022 7:07 PM, Matthew Martin wrote:
> On Mon, Nov 07, 2022 at 06:18:15PM -0600, Clinton Bunch wrote:
> > Here's the updated patch taking into account the feedback I got from Bart
> > and dana.
> >
> > -l length has been converted to -c count
> >
> > -L is placed before -U in the documentation
> >
> > Documentation specifies that -r (raw) is for binary data.
> >
> > Range checking has been added to the -L and -U options
> >
> > Bug where -i overrode -L or -U has been fixed.  Bounds take precedence even
> > if -i is redundantly specified.
> >
> > Default count has been changed to 1 if -i, -L, and/or -U has been specified
> > without -a
> >
> > dana's completion function has been updated with these changes and included
> >
> > A test file has been created (Not sure how useful it is, but it's there)
> 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



>