On Sat, Nov 05, 2016 at 10:47:07AM +0100, minek van wrote:
> It is sad to see that something is stated "RANDOM" and it is in reality not
> random and still in OpenBSD. This misleads people.
As other's have said, the manual states exactly what's happening. With
a bit of imagination, it's easy to "fix" it:
strings /dev/arandom | grep -o '[[:print:]]' | head -100 |
awk '{ print NR, $0 }' | sort -R | cut -d' ' -f2
Done
Cheers,
Andreas
>
>
> > Sent: Friday, November 04, 2016 at 7:27 PM
> > From: Shazaum <shaz...@bsd.com.br>
> > To: misc@openbsd.org
> > Subject: Re: Why isn't "sort -R" random?
> >
> > Sorry for saying this, but debian it would not be wrong...
> >
> > # sort -R a.txt
> > 7
> > 7
> > 7
> > 7
> > ...
> >
> > On 11/04/2016 02:17 PM, Joel Wir��mu Pauling wrote:
> > > Pipe through uniq and you'll get what you are after.
> > >
> > > Design intent for sort, as others point out this behaviour is
documented.
> > >
> > > On 4 November 2016 at 11:47, Christian Gruhl <cgr...@uni-kassel.de>
> wrote:
> > >
> > >> Hi minek,
> > >>
> > >> On 11/04/2016 04:41 PM, minek van wrote:
> > >>> Hello,
> > >>>
> > >>> # strings /dev/arandom | grep -o '[[:print:]]' | head -100 > a.txt
> > >>> # sort -R a.txt
> > >>> K
> > >> ...
> > >>> 9
> > >>> # uname -mrs
> > >>> OpenBSD 6.0 amd64
> > >>> #
> > >>> # sort -R a.txt > b.txt
> > >>> # cksum b.txt
> > >>> 3374888359 200 b.txt
> > >>> # sort -R a.txt > b.txt
> > >>> # cksum b.txt
> > >>> 109071951 200 b.txt
> > >>> # sort -R a.txt > b.txt
> > >>> # cksum b.txt
> > >>> 3441576000 200 b.txt
> > >>> #
> > >>>
> > >>> from: http://man.openbsd.org/OpenBSD-current/man1/sort.1
> > >>>
> > >>> -R, --random-sort, --sort=random
> > >>>
> > >>> Sort lines in random order. This is a random permutation of the
> > >> inputs with the exception that equal keys sort together. It is
> > >> implemented by hashing the input keys and sorting the hash values. The
> > >> hash function is randomized with data from arc4random_buf(3), or by
file
> > >> content if one is specified via --random-source. If multiple sort
fields
> > >> are specified, the same random hash function is used for all of them.
> > >>> Although the "b.txt" differs, if we check it by the human eye... that
> > >> is not random.. **Why**? Why is it called random, WHEN IT IS NOT
> > >> RANDOM?! Random should mean RANDOM. Not "almost" random..
> > >>> The same can be seen on ex.: RHEL7.
> > >>>
> > >> I would guess this is the desired behavior. The man page cited by you
> > >> also states:
> > >>
> > >> 'This is a random permutation of the inputs with the exception that
> > >> equal keys sort together. It is implemented by hashing the input keys
> > >> and sorting the hash values.'
> > >>
> > >> So clearly same values/strings will be put together.
> > >>
> > >> Best wishes
> > >>
> > >> Chris
> > >>
> > >> [demime 1.01d removed an attachment of type
application/pkcs7-signature
> > >> which had a name of smime.p7s]
>
--
Andreas Kusalananda Kähäri
Bioinformatics Developer
NBIS, Uppsala University
http://www.nbis.se/
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
