> On 2023-03-07, at 11:53 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > > 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.<make-check-log.txt.gz><0001-split-support-split-n-on-larger-pipe-input.patch>
Hi Paul! Here are the latest test results on macOS 12.6.3: threshold.sh: skipped test: block size of a directory is smaller than 4 bytes SKIP: tests/du/threshold.sh It was also skipped on macOS before the patch, so no change. https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-10-16000805eb1bcdf25360471b8bbc8ec3f025e035-ori.txt The folks at OpenWRT asked for an update on the conreutils-9.2 release date? I will let them know the sparse copy fix is already on Savannah master. Good luck! Georgi Valkov httpstorm.com nano RTOS
