Matt Keenan <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> [snip snip] >> I agree, and think I wrote exactly the same thing: uniq needs the >> same >> -k key-selection options as sort -- probably in response to a request >> to integrate the Debian patch. I went to look for it a couple days ago, >> but got side-tracked. > > I am happy to write a patch. Just a quick note, I would have thought > that the Debian patch was released under a GPL license, and hence I > wouldn't need to request permission (as the permission was already > granted by the license). I will check the license anyway before I check > the code and do a clean room implementation from scratch if necessary..
Hi Matt, I'm glad you're willing to work on this. It's an often-requested feature. Unfortunately, the Debian -W patch was not acceptable. It did not allow the same flexibility that sort does in selecting keys. To provide that, GNU uniq will eventually accept at least the following options, just as sort does: -k, --key=POS1[,POS2] start a key at POS1, end it at POS2 (origin 1) -t, --field-separator=SEP use SEP instead of non-blank to blank transition -z, --zero-terminated end lines with 0 byte, not newline and even most, if not all, of these (for flexibility/interoperability with sort, as well as to ease code sharing between uniq and sort): -b, --ignore-leading-blanks ignore leading blanks -d, --dictionary-order consider only blanks and alphanumeric characters -f, --ignore-case fold lower case to upper case characters -g, --general-numeric-sort compare according to general numerical value -i, --ignore-nonprinting consider only printable characters -M, --month-sort compare (unknown) < `JAN' < ... < `DEC' -n, --numeric-sort compare according to string numerical value -r, --reverse reverse the result of comparisons This means that there will be an additional challenge: find a clean way to share the code in sort.c that implements the above options. As for paperwork, the GNU project requires a copyright assignment and/or disclaimer of anyone who ends up contributing more than about 10 lines of code. If you're still interested, let me know and we can get the paperwork started -- that process can easily take longer than writing the code, so it's best to start asap. Jim _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils