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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
