Re: sort --random-sort

[Paul Eggert]

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?

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'.

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
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

Do not generate more than NLINES of output.  NLINES defaults to infinity.

--replace

Output lines with replacement, so that the same input line can be
output more than once.  (The default is to output them without
replacement.)  If this option is the only one specified, and if the
input is non empty, then 'rand' will output lines indefinitely, until
it is stopped by other means (e.g., --count, write error).

--echo

Treat each operand as an input line.  (Ignore standard input.)  For
example, 'rand --echo a b c' is equivalent to (echo a; echo b; echo c) | rand.

--merge

Treat each operand as an input file name.  Generate a random merge of
the files.  In other words, the output is chosen randomly from the set
of all possible merges of the N input files.  This option cannot be
combined with --echo or --replace.

--output FILE

Send output to FILE rather than standard output.  FILE can be one of
the input files, unless --merge is also specified.