GNU bug report logs - #67593
`split --number=l/N` no longer splits evenly

Previous Next

Full log

Message #8 received at 67593 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Victor Engmark <victor <at> engmark.name>
Cc: 67593 <at> debbugs.gnu.org
Subject: Re: bug#67593: `split --number=l/N` no longer splits evenly
Date: Sun, 3 Dec 2023 01:37:37 -0800

That's not a bug, in that 'split' is behaving as documented. The first 
input line is one byte shorter than the second one. 'Split' divides the 
input into two regions, and because the first region happens to be one 
byte longer than the second region both input lines are sent to the 
first output file.

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 in

created 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.