Re: sort --random-sort

[Jim Meyering]

Hi Paul,

Paul Eggert <address@hidden> wrote:
> I'm puzzled as to why, in this day and age, shred (and any other
> programs that might need lots of hard-to-guess random numbers) needs
> to have its own random number generator.  Why can't such programs just
> read /dev/urandom?  Is it because they need to fall back on something
> on hosts that lack /dev/urandom?

I suspect that was Colin's (shred-author's) motivation.
If we were to use /dev/urandom, we'd have to handle unusual
cases like open failure, EOF, and read error, and hence would
need a fall-back position, regardless.

I do agree that it'd be better to use /dev/urandom, when possible.
The resulting interface to a gnulib-like module would have to record
state, including a file descriptor or FILE* as well as state for a
fall-back random number generator.

> Also, the more I think about it, the less I like folding this stuff
> into 'sort'.  It really should be a separate program, as it's an ill
> fit for 'sort'.

I too like the idea of a separate program to permute its input lines,
but there are some applications for which permuting only lines with,
say the same primary sort key, is practical:

  http://lists.gnu.org/archive/html/bug-coreutils/2005-02/msg00005.html

I'd welcome a separate program, in addition to the sort option.

> How about this as an initial cut for an interface?  Let's call the
> program 'rand' (perhaps we can think of a better name later).  By

I'd expect a program named `rand' to output random numbers.
Maybe something like `permute' or `pmt'?

> default, 'rand' reads lines from stdin and outputs a random
> permutation of those lines.  If one operand is given, 'rand' reads
> from the named input file rather than from standard input.  Here are
> some options:
>
> --count NLINES

It needs a --seed=SEED option, too, of course.