sort/uniq/join: key-comparison code consolidation

[Assaf Gordon]

Hello,

( new thread for previous topic 
http://lists.gnu.org/archive/html/coreutils/2013-02/msg00082.html ) .

The attached patch contains:
====
1. src/key-spec-parsing.{h,c} - key comparison code, previously in sort.c

2. uniq - now supports "--key" (multiple keys, too).
Same as before, but rebased against 8.21.
Supported orders:
  -k1,1  = ascii
  -k1b,1 = ignore-blanks
  -k1d,1 = dictionary
  -k1i,1 = non-printing
  -k1f,1 = ignore-case
  -k1n,1 = fast-numeric
  -k1g,1 = general-numeric
  -k1M,1 = month
also supports user-specified delimiter (default: white-space).

Related discussions:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5832
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7068
  http://lists.gnu.org/archive/html/bug-coreutils/2006-06/msg00211.html

3. sort - same functionality as before, but key-comparison code extracted to a 
different file.

4. join - internally uses the key-comparison code.
Does not support the "--key" parameter (uses the standard -j/-1/-2),
but accepts new arguments that affect joining order:
 -r --reverse
 -n --numeric-sort
 -d --dictionary-order
 -g --general-numeric

Related discussions:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6903
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6366

As an option, perhaps we can support new "-k" that will be like "-j" but allow 
specificity options
(e.g. "-k1nr" will be equivalent to "-j 1 --numeric --reverse").
==== 

It'll be easy to add human-numeric-sort/version-sort to join/uniq, but I'm not 
sure if they make sense.


Regards,
 -gordon

key_compare7.patch.xz
Description: application/xz