[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3
From: |
Bernhard Voelker |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
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
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Philipp Thomas, 2013/12/05
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Paul Eggert, 2013/12/06
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Pádraig Brady, 2013/12/06
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Bernhard Voelker, 2013/12/06
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Pádraig Brady, 2013/12/06
- bug#16061: Error in the message for src/shuf.c:73 in 8.22-pre3, Bernhard Voelker, 2013/12/06