[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils-bug
Subject:    Re: RFC: add'l 'sort -n' options
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2006-11-07 0:15:44
Message-ID: eioj7g$idd$1 () sea ! gmane ! org
[Download RAW message or body]

Paul Eggert wrote:
> Matthew Woehlke <mw_triad@users.sourceforge.net> writes:
>> Since it seems we've mostly shot down the -N idea in favor of explicit
>> options
> 
> Not at all.  I'd rather not chew up a lot of option letters for this
> problem, as we're running short of option letters.  So having an -N
> option (with subletters) is preferable.  We just need a way to combine
> this with -k.  Perhaps something like '-k3Nv,r', which would act like
> -Nv -r -k3 except that the -Nv and -r options are attached only to the
> -k option?  Or even (more generally) '-k3--numeric,--reverse'?

Ok, I can do that too. :-) In which case, however, I would definitely 
make an alias for the existing -g. But yeah, supporting 
'-k<fieldspec>N<opt-letters>[,<option>...]' seems to be 'The Right Thing 
to Do'.

Hmm, I really want '-r' now... I just realized it would solve sorting 
(mainly for 'sort | uniq') error messages from build logs, i.e. things like:

foo.c:5 warning blah blah
foo.c:12 warning blah blah
bar.c:201 error blah blah

...which is something I do all the time. :-)
(Although really 'uniq' that doesn't need consecutive lines would be 
more "correct", but...)

-- 
Matthew
If this message is intercepted, the sender will disavow all knowledge of 
its existence.




[prev in list] [next in list] [prev in thread] [next in thread]