Hi Jim,
> I hope the end-of-term business went well. Pretty well, thanks for asking > 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. > 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. 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.
