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 ;)
