|
From: | Paul Eggert |
Subject: | bug#67593: `split --number=l/N` no longer splits evenly |
Date: | Sun, 3 Dec 2023 01:37:37 -0800 |
User-agent: | Mozilla Thunderbird |
In older coreutils, 'split' used a different algorithm to compute region sizes, which worked better for your test case but considerably worse in others. For example, in older coreutils:
seq 50 >in split -n l/71 increated 43 files of size 0, 9 files of size 2, 18 files of size 3, and one file of size 69. Current coreutils splits much better: it creates 21 files of size 0, 9 files of size 2, and 41 files of size 3.
[Prev in Thread] | Current Thread | [Next in Thread] |