bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number

[Erik Auerswald]

Hi,


On Fri, Jun 25, 2021 at 08:54:43AM +0200, Erik Auerswald wrote:
> On Fri, Jun 25, 2021 at 08:49:51AM +0200, Erik Auerswald wrote:
> > On Thu, Jun 24, 2021 at 09:19:36PM -0700, Paul Eggert wrote:
> > > On 6/24/21 4:46 PM, F8ER F8ER wrote:
> > > >For example, `shuf -i 101-100 -n 1` returns nothing with the exit code
> > > >= 0 (unexpected).
> > > 
> > > Actually, it's the expected behavior. It's the same behavior as
> > > 'shuf -n 1 </dev/null'. The '-n 1' option does not mean "output
> > > exactly 1 line"; it means "output at most 1 line".
> > 
> > I think the reported issue is with producing no error with LO==HI+1,
> > but producing an error with LO<HI+1:
>                                 ^
>                               LO>HI+1

The code seems to intentionally silently ignore LO == HI+1, but not
LO > HI+1.  But this is neither documented nor tested.  This may be
an intentionally interesting way to simulate reading from an empty
file containing no lines between LO and HI.

Please see my previous patch as a suggestion on how to make the code
less suprising.

I am fine with keeping the current behavior, but then I'd like to
document it and add test cases.  Please let me know if you'd rather
have a documentation change & tests patch than the current code
change & tests patch.

I do think that it would be better to either change the code or the
documentation, and add test cases, than to do nothing.

Thanks,
Erik
-- 
Simplicity is prerequisite for reliability.
                        -- Edsger W. Dijkstra