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