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]
