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