GNU bug report logs - #16061
Error in the message for src/shuf.c:73 in 8.22-pre3

Previous Next

Full log

View this message in rfc822 format

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Philipp Thomas <pth <at> suse.de>, Assaf Gordon <assafgordon <at> gmail.com>, 16061 <at> debbugs.gnu.org
Subject: bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3
Date: Fri, 06 Dec 2013 02:26:43 +0100

On 12/06/2013 02:13 AM, Pádraig Brady wrote:
> On 12/06/2013 12:15 AM, Bernhard Voelker wrote:
>> On 12/06/2013 12:37 AM, Pádraig Brady wrote:
>>> diff --git a/src/shuf.c b/src/shuf.c
>>> index f7fc936..4d0ae90 100644
>>> --- a/src/shuf.c
>>> +++ b/src/shuf.c
>>> @@ -76,8 +76,8 @@ Write a random permutation of the input lines to standard output.\n\
>>>    -n, --head-count=COUNT    output at most COUNT lines\n\
>>>    -o, --output=FILE         write result to FILE instead of standard output\n\
>>>        --random-source=FILE  get random bytes from FILE\n\
>>> -  -r, --repetitions         output COUNT items, allowing repetition.\n\
>>> -                              -n 1 is implied if not specified.\n\
>>> +  -r, --repetitions         allow repetition within a specified --head-count\n\
>>> +                              which is assumed to be 1, if not specified.\n\
>>
>> n=1 is not really a repetition. ;-)
>>
>> BTW: What was the reason to default n=1 with -r anyway?
>> I mean as the user did not specify any limit he may assume
>> the same number as in the input, like without -r.
> 
> Well --repetitions means --allow-repetitions and in this mode
> we're just picking random items from the input.
> So it doesn't make much sense then to output the same number
> of items as was input in this mode. It makes more sense to
> default to picking a single random item. Now granted that is
> a bit of an awkward default in the context of the --repetitions name.
> Though you could read `gen_data | shuf -r` as pick a
> random item from the data, which is less awkward.

Thanks, with this explanation, this default makes sense, agreed.

> I suppose we could make -r require that -n is specified,
> but I'm not sure.

Regarding this in the above context - no, because then you would
have to specify -n1 when "picking 1 random item". Saving the user
from typing -n1 seems to be _the_ reason for assuming n=1.

> Other edge cases I've now noticed...
> 
> -n1 could degenerate to the faster --repetitions mode in all cases
> -n0 -r should exit without reading input
> 
> These edge case fixes are not worth adding to this release though.

Agreed.

Thanks & have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.