On 12/01/2021 03:17, William Bader wrote:
I think that split has to be able to read from pipes, so if it reads to the end to find the number of lines, it can't back up to do the split. If you don't care about the order of the lines, you could use "split --number=r/2"
Good point RE --number=r/2 being an option. Reading from pipes is only partly the reason we don't support this functionality. The same arguments can be applied to "bytes" and "lines" as enumerators, and we support this functionality with bytes. Though when reading from pipes we error out as appropriate: $ split -n2 - split: -: cannot determine file size If we we're to support this, we'd add something like the following to --number: L/N split into N files with an equal number of lines per file L/K/N output Kth of N to stdout with equal number of lines per file The disadvantage is that we'd be pulling some wc logic into split, but it wouldn't be providing any efficiency advantages. Achieving this in shell is also simple enough and portable lines=$(($(wc -l < "file") / 2)) split -l $lines file Now L/K/N above would be new functionality provided, though I'm not sure if it's useful enough to warrant the addition. I'm 50:50. cheers, Pádraig
