On 3/6/23 03:13, Pádraig Brady wrote:
> On 06/03/2023 07:37, Paul Eggert wrote:
> The lseek /dev/null issue was only in your undef SEEK_DATA test patch,
> and already addressed in your final gnulib patch in the area, as 
> discussed at:
> https://lists.gnu.org/archive/html/bug-coreutils/2023-02/msg00081.html

Sorry,  I got confused about that issue versus other 'split' issues.


> Also immediately rejecting input where we can't determine the size is a 
> feature.
> I.e. the following is the expected behavior:
> 
>    $ : | split -n l/1
>    split: -: cannot determine file size

But 'split' can easily determine the size there: it's zero. 'split' 
doesn't need to use lseek to do that; a single 'read' will do.


> With the changes we now have:
> 
>    $ : | split -n l/1  # Creates an empty file
>    $ yes | split -n l/1
>    split: -: cannot determine file size
> 
> This is inconsistent, and an insidious issue that users may introduce to 
> scripts,
> that will only fail once input data hits a certain size.

That's OK, as lots of standard utilities already have that issue and 
users are OK with this. Users can't reasonably expect 'split -n' to work 
on infinitely-sized input such as the second example. At some point 
there is a limit.

It's a bit like 'sort' if you feed 'sort' longer and longer input lines, 
eventually it will fail and give you a diagnostic.

It'd be nicer if the limit of 'split' were larger than what's in current 
Git. If you'd prefer that we raise the limit further, by copying stdin 
into a temporary file first, I can write a patch to do that.


> Also there are a few `make syntax-check` issues in the new split code.

Ouch, sorry, I'm always forgetting that. Fixed by the attached patch. 
(Two of the issues were in 'split', one was elsewhere.)


> Would it be possible to revert this change in isolation?

We could revert the patch's effect (not sure if it's a simple revert, 
but I could easily generate such a patch). I'm hoping, though, that we 
can reach consensus on extending split's functionality instead, perhaps 
along the abovementioned lines.

[dropping bug-gnulib since this is no longer relevant to Gnulib.]