Chen Guo wrote:
...
It's good to make long option names consistent between tools,
and to avoid long, common prefixes like "--number-".
Have you considered --bytes and --lines, like tail has?
Unfortunately split already uses the long options --bytes and --lines.
One possibility is to stick with the existing long option names,
but let an argument of the form "K/N" evoke the new semantics:
--bytes=K/N extract the K'th of N portions (byte-oriented)
--lines=K/N extract the K'th of N portions (line-oriented)
Since tail's -n means --lines, making "split -n 4" mean "bytes"
would be confusing.
Using a short option name like -n *may* be fine,
but you have to do a survey of all other vendor
versions of split to ensure that none of them
provide an -n option.
We're kinda stuck between a rock and a hard place. Originally
Padraig suggested -n at least in part to maintain compatibility with
BSD's split. On one hand, keeping it -n would be conflicting with
tail and head, but on the other hand not using -n would conflict with
BSD.
Actually, now that I think a little more about it, using "-n N" to mean
split on bytes makes sense, since split is primarily a byte-oriented tool,
unlike head and tail, which seem to be more line-oriented by default.