On 3/6/23 16:31, Pádraig Brady wrote:
syntax check now looks good thanks.
You're welcome. I'm getting a failure on tests/du/threshold.sh, though,
on Fedora 37 x86-64. Are you seeing that? See attached (compressed) log.
I see this as a more fundamental operational thing than a limit issue.
`split -n` needing the size up front alludes to the operation,
To ameliorate a bit, we can document this (done in the attached patch).
I don't see this as being significantly more serious than the other
utilities that read all their input (possibly from a pipe) before
outputting anything. They all need to deal with exhausting temporary
space, and 'split' is merely joining the company of 'sort' and 'tac'.
given split is often used with large data,
explicit control is often desired over where and how it's persisted.
Anybody needing that control can copy the data themselves to a temp
file, before calling 'split'. (Like 'sort' and 'tac'.)
Since the change doesn't invalidate existing uses, it sounds like you're
worried that users will want 'split' to work even on enormous pipe
inputs, inputs so large that /tmp fills up. I think this unlikely in
practice, but if it turns into a real concern I can work around most of
the problem by using the first output file as the temporary. However,
I'd prefer to avoid doing this unless it's necessary, as it seems overkill.
I installed the attached patch so that 'split' uses a temp file in this
situation, so it is no longer limited to the 128 KiB size that it was
before the attached patch. Hope this is good enough; if not please let
me know.