Re: [PATCH] split: --chunks option

[Jim Meyering]

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.

> I'm under the impression that most Linux distributions use the GNU
> implementation of split. BSD compatibility is our target, and as for
> Solaris, I'm not sure if they use ours or their own, but there is no -n
> option in their man page. I've only been exposed to open source
> software for a year and a half, so I might be missing some duh ones.
> Please let me know.
>
> And a general progress report: of the four new features to be added,
> only splitting evenly into output files with newline delineation is left,
> and of course figuring outthis options stuff.

Good to hear ;)