bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
Hi Paul, On Fri, Jun 25, 2021 at 09:29:04AM -0700, Paul Eggert wrote: > On 6/24/21 11:49 PM, Erik Auerswald wrote: > > $ shuf -i 2-0 ; echo %exit code $? > > shuf: invalid input range: ‘2-0’ > > %exit code 1 > > $ shuf -i 1-0 ; echo %exit code $? > > %exit code 0 > > > >This looks inconsistent and possibly not exactly as intended. > > It's exactly what I intended and there's no inconsistency. When you > say 'shuf -i M-N' you select from a collection of N-M+1 lines. It also specifies the contents of those lines, unless there is less than one line. > N-M+1 = 0 (no input lines) makes sense, but N-M+1 < 0 (negative number > of input lines?) does not. I do not think that it makes sense to specify the contents of no input lines. Perhaps we can agree to disagree on this? Then the documentation does not describe it that way. I think that can lead to confusion. The documentation describes the option as simulating input "from a file containing the range of unsigned decimal integers LO...HI, one per line." >From this description it is not obvious that "1-0" is OK, but "2-0" is not. In both cases LO > HI, but one is accepted without error, but the other is not. I think that "select from a negative number of lines" makes just as much sense as "select from no lines at all." Here we seem to disagree, which is OK with me. Similarly to "shuf -iLO-HI", "seq FIRST LAST" produces LAST-FIRST+1 lines. But seq does allow to ask, to adapt your wording, for a negative number of lines: $ seq 2 0 ; echo %exit code $? %exit code 0 $ seq 1 0 ; echo %exit code $? %exit code 0 $ seq 0 0 ; echo %exit code $? 0 %exit code 0 The problem I see is that the intention behind "shuf -i" that can be gleaned from your implementation, and that you have described above, is not obvious from the documentation or from similar functionality in the GNU Core Utilities. I see three views regarding the case of LO > HI in this thread: 1. The bug reporter expected LO > HI to always produce an error, or possibly to never produce an error. 2. Your "shuf" implementation sees LO == HI+1 as the one allowed possibility to specify no input, based on the HI-LO+1 formula for the number of lines to choose from. 3. The "seq" implementation in the GNU Core Utilities allows LO > HI and interprets it as the empty sequence. I actually like this best. Thus I think that it is not as clear and obvious as you seem to expect that the current "shuf" behavior is the obviously correct one. No offense intended! I do not care deeply which behavior is selected. I just want to make it clearer for others, including me, to understand that the current implementation is as intended. Adding to the documentation (for users) and the tests (for developers) seems to be helpful to me. > >I'd like to document it and add test cases. > > Feel free, Thanks, I'll think about a wording both simple to understand and including the special case. I intend to send a patch to this bug report in a couple of days. > though we need to reserve the right to extend 'shuf' in > the future. In other words, not every invocation of 'shuf' that > provokes a diagnostic now will provoke a diagnostic in the future. I like that. HTH, HAND, Erik -- Be water, my friend. -- Bruce Lee
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
On 6/24/21 11:49 PM, Erik Auerswald wrote: $ shuf -i 2-0 ; echo %exit code $? shuf: invalid input range: ‘2-0’ %exit code 1 $ shuf -i 1-0 ; echo %exit code $? %exit code 0 This looks inconsistent and possibly not exactly as intended. It's exactly what I intended and there's no inconsistency. When you say 'shuf -i M-N' you select from a collection of N-M+1 lines. N-M+1 = 0 (no input lines) makes sense, but N-M+1 < 0 (negative number of input lines?) does not. I'd like to document it and add test cases. Feel free, though we need to reserve the right to extend 'shuf' in the future. In other words, not every invocation of 'shuf' that provokes a diagnostic now will provoke a diagnostic in the future.
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
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 > > 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 ^ > 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
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
Hi, 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 > 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 LOHI+1 Sorry! Thanks, Erik -- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
Hi, 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 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
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
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 it means "output at most 1 line".
bug#49217: 'shuf' returns nothing if the low range number is higher by 1 than the high number
Dear GNU Developers, Thank you very much for the project. It seems, if the low range number is higher by 1 than the high number, the program returns nothing (with exit code = 0), while 102-100 results in an error and 100-100 returns 100 as expected. For example, `shuf -i 101-100 -n 1` returns nothing with the exit code = 0 (unexpected). Expected (normal): `shuf -i 100-101 -n 1` returns either 100 or 101 with an exit code = 0. `shuf -i 100-100 -n 1` returns 100 with an exit code = 0. `shuf -i 102-100 -n 1` results in an error with an exit code = 1. Is that an expected behavior? Stay safe! Best and kind regards
