On Tue, 27 Dec 2016 11:32:32 +0100 Laslo Hunhold <[email protected]> wrote:
> On Sat, 26 Mar 2016 13:50:47 +0100 > Mattias Andrée <[email protected]> wrote: > > Hey Mattias, > > > +static int > > +random_byte_file(void) > > +{ > > + unsigned char r; > > + ssize_t n = read(source, &r, 1); > > + if (n < 0) > > + eprintf("read %s:", sflag); > > + if (!n) > > + eprintf("read %s: end of file > > reached\n"); > > + return r; > > +} > > + > > +static int > > +random_byte_libc(void) > > +{ > > + double r; > > + r = rand(); > > + r /= (double)RAND_MAX + 1; > > + r *= 256; > > + return (int)r; > > +} > > is there a good reason for the existence of shuf(1)? > Also, we may want to think about using more solid > interfaces for randomness (like arc4random()) and remove > the "file-source" altogether. > > Cheers > > Laslo > Hi Laslo! No, we don't really need shuf(1) in sbase, but I think we should have a suckless implementation available, it can be a useful utility. I have a few more utilities I fund useful but I haven't bothered to set up a repository yet. I tried to start a discussion with Dimitris some time ago, but I didn't get a response. I think it might be a good idea to have sextra for portable utilities and uextra for unportable utilities, if you have any other suggestions I would like to hear them. For sextra I have written base16(1), base32(1), base64(1), prune(1) which recursively removes empty directories, rev(1) and shuf(1). For uextra I have written fsize(1) which print the size of any regular file or block device (other do not print the size of block devices so it can be quite burdensome to find out how large one is), printenvx(1) which is like printenv(1) but for other processes, and shred(1), and I'm working on rescue(1) which is similar to ddrescue(1). I'm not sure that arc4random() is portable, but my understanding is that each bit in the output of rand() have the same entropy in modern libc implementations, and that is all that is needed in my opinion. I don't know whether it is a good to include reading random data from files, so it should probably be removed. Mattias Andrée
pgpx8wQCYP9j2.pgp
Description: OpenPGP digital signature
