GNU bug report logs - #10019
sort options -Mn are incompatible

Previous Next

Package: coreutils;

Reported by: Lars Noodén <lars.nooden <at> gmail.com>

Date: Fri, 11 Nov 2011 17:10:01 UTC

Severity: normal

Tags: moreinfo, notabug

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10019 in the body.
You can then email your comments to 10019 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 17:10:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lars Noodén <lars.nooden <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Fri, 11 Nov 2011 17:10:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Noodén <lars.nooden <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 15:55:48 +0200
Since the sort options -M and -n are incompatible, there appears to be 
no easy way to sort log files.

/Lars




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 18:03:02 GMT) Full text and rfc822 format available.

Message #8 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 11:02:37 -0700
tags 10019 + moreinfo notabug
thanks

Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to
> be no easy way to sort log files.

Unfortunately your bug report doesn't include enough information to
understand what you are reporting.  It does not make sense that you
would have a sort field that is *both* a month *and* numeric and by
which you would want to sort by *both* on the same field.  Of course
numerically is not the same as by month and by month is not the same
as numerically.  They cannot be "compatible" by definition.

You did not include a small example to illustrate what you wanted to
do.  Without that I can only guess at things.  Also the program
version is important too.  Please include that information in the bug
report.

Perhaps you are actually trying to sort *different* fields using
different sort methods?  If so then perhaps you are not aware of the
sort -k option which is to be used when you wish to sort different
fields with different keys.  The documentation for sort -k says:

`-k POS1[,POS2]'
`--key=POS1[,POS2]'
     Specify a sort field that consists of the part of the line between
     POS1 and POS2 (or the end of the line, if POS2 is omitted),
     _inclusive_.

     Each POS has the form `F[.C][OPTS]', where F is the number of the
     field to use, and C is the number of the first character from the
     beginning of the field.  Fields and character positions are
     numbered starting with 1; a character position of zero in POS2
     indicates the field's last character.  If `.C' is omitted from
     POS1, it defaults to 1 (the beginning of the field); if omitted
     from POS2, it defaults to 0 (the end of the field).  OPTS are
     ordering options, allowing individual keys to be sorted according
     to different rules; see below for details.  Keys can span multiple
     fields.

     Example:  To sort on the second field, use `--key=2,2' (`-k 2,2').
     See below for more notes on keys and more examples.  See also the
     `--debug' option to help determine the part of the line being used
     in the sort.

If you wish to sort one field by month and one field numbered you
would specify that with different fields.  You mentioned log files so
let me propose a simple log file example.  This is off the top of my
head and perhaps wrong but should at least get you pointed in the
right direction.

  $ printf "
Nov 11 06:54:44 foo did something
Nov 11 06:55:25 bar did another something else
Nov 11 10:53:38 zoo reported
Feb  7 11:23:43 zoo reported
" | sort -s -k1M,1 -k2n,2 -k3,3 -k4,4

Feb  7 11:23:43 zoo reported
Nov 11 06:54:44 foo did something
Nov 11 06:55:25 bar did another something else
Nov 11 10:53:38 zoo reported

Bob




Added tag(s) notabug and moreinfo. Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Fri, 11 Nov 2011 18:03:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 18:39:01 GMT) Full text and rfc822 format available.

Message #13 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 18:11:00 +0000
On 11/11/2011 01:55 PM, Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to be no easy way to sort log files.

Sorry if you get a dupe.
My last was sent to 10019-done which I think crossed with Bob's
mail to the same address and was dropped?
I'm not even sure this will go to the list since the
bug is now closed, but for the record...

Here is a recipe I use for sorting access_log files,
which avoids numeric conversion as they're fixed width fields.

  sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log

Though one could use -M and -n on separate fields like `-k1,1M -k2,2n`

Note also the --debug option on recent versions of sort
which helps one figure this out, including subtleties like
needing the b after the M even though a global -b was specified.

cheers,
Pádraig.




Reply sent to Pádraig Brady <P <at> draigBrady.com>:
You have taken responsibility. (Fri, 11 Nov 2011 18:54:02 GMT) Full text and rfc822 format available.

Notification sent to Lars Noodén <lars.nooden <at> gmail.com>:
bug acknowledged by developer. (Fri, 11 Nov 2011 18:54:02 GMT) Full text and rfc822 format available.

Message #18 received at 10019-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019-done <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 17:55:33 +0000
tag 10019 notabug

On 11/11/2011 01:55 PM, Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to be no easy way to sort log files.

Here is a recipe I use for sorting access_log files,
which avoids numeric conversion as they're fixed width fields.

  sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log

Though one could use -M and -n on separate fields like `-k1,1M -k2,2n`

Note also the --debug option on recent versions of sort
which helps one figure this out, including subtleties like
needing the b after the M even though a global -b was specified.

cheers,
Pádraig.




Message #19 received at 10019-done <at> debbugs.gnu.org (full text, mbox):

From: Lars Noodén <lars.nooden <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10019-done <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 21:09:33 +0200
On 11/11/11 7:55 PM, Pádraig Brady wrote:
> tag 10019 notabug
>
> On 11/11/2011 01:55 PM, Lars Noodén wrote:
>> Since the sort options -M and -n are incompatible, there appears to be no easy way to sort log files.
>
> Here is a recipe I use for sorting access_log files,
> which avoids numeric conversion as they're fixed width fields.
>
>    sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
>
> Though one could use -M and -n on separate fields like `-k1,1M -k2,2n`

Yes, thanks, that does the job.

However, from the manual page it was not clear that this could be done. 
 Now that I know the answer, this part seems relevant:

	OPTS  is  one  or  more  single-letter  ordering
	options,  which  override  global ordering options for
	that key.

Perhaps it could be made more clear with an example or a list of the 
options.

/Lars

> Note also the --debug option on recent versions of sort
> which helps one figure this out, including subtleties like
> needing the b after the M even though a global -b was specified.
>
> cheers,
> Pádraig.





Message #20 received at 10019-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019-done <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 19:25:35 +0000
On 11/11/2011 07:09 PM, Lars Noodén wrote:
> On 11/11/11 7:55 PM, Pádraig Brady wrote:
>> tag 10019 notabug
>>
>> On 11/11/2011 01:55 PM, Lars Noodén wrote:
>>> Since the sort options -M and -n are incompatible, there appears to be no easy way to sort log files.
>>
>> Here is a recipe I use for sorting access_log files,
>> which avoids numeric conversion as they're fixed width fields.
>>
>>    sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
>>
>> Though one could use -M and -n on separate fields like `-k1,1M -k2,2n`
> 
> Yes, thanks, that does the job.
> 
> However, from the manual page it was not clear that this could be done.  Now that I know the answer, this part seems relevant:
> 
>     OPTS  is  one  or  more  single-letter  ordering
>     options,  which  override  global ordering options for
>     that key.
> 
> Perhaps it could be made more clear with an example or a list of the options.

There is always a trade-off between brevity and completeness
we're trying to achieve in the man pages. For the full
documentation see the info pages.

Now most people I know never read the info pages,
because of the barrier to entry of the default reader.
The required keys to remember are quite few really:

  http://www.pixelbeat.org/lkdb/info.html

Hmm I wonder could we build and install the html manual
on GNU/Linux distros at least and then provide this in the man page:

  xdg-open $(file:///usr/share/doc/coreutils-x.xx/doc/coreutils.html#sort-invocation)

cheers,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 19:29:01 GMT) Full text and rfc822 format available.

Message #23 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 10:34:42 -0700
[Message part 1 (text/plain, inline)]
tag 10019 moreinfo
thanks

On 11/11/2011 06:55 AM, Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to be
> no easy way to sort log files.

Not true, if you use -k to separate the sort into non-overlapping keys.
 Please post an example of 2 or 3 lines you'd like sorted, and then we
can help you figure out the correct command line.  For example,

sort -k1,1M -k2,2nb

would sort lines where the first field is a month name and the second
field is a day within the month, with all ties being broken by comparing
the overall line.

I'm guessing that there is no bug in sort, but I'll wait for more info
from you of an actual sample of the lines you want sorted, what you
tried, what you got, and a comparison to what you wanted, before
declaring this as not a bug.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #24 received at 10019-done <at> debbugs.gnu.org (full text, mbox):

From: Lars Noodén <lars.nooden <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10019-done <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 21:31:36 +0200
On 11/11/11 9:25 PM, Pádraig Brady wrote:
> On 11/11/2011 07:09 PM, Lars Noodén wrote:
>> On 11/11/11 7:55 PM, Pádraig Brady wrote:
>>> tag 10019 notabug
>>>
>>> On 11/11/2011 01:55 PM, Lars Noodén wrote:
>>>> Since the sort options -M and -n are incompatible, there
>>>> appears to be no easy way to sort log files.
>>>
>>> Here is a recipe I use for sorting access_log files, which avoids
>>> numeric conversion as they're fixed width fields.
>>>
>>> sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
>>>
>>> Though one could use -M and -n on separate fields like `-k1,1M
>>> -k2,2n`
>>
>> Yes, thanks, that does the job.
>>
>> However, from the manual page it was not clear that this could be
>> done.  Now that I know the answer, this part seems relevant:
>>
>> OPTS  is  one  or  more  single-letter  ordering options,  which
>> override  global ordering options for that key.
>>
>> Perhaps it could be made more clear with an example or a list of
>> the options.
>
> There is always a trade-off between brevity and completeness we're
> trying to achieve in the man pages. For the full documentation see
> the info pages.

It's a little too brief as it is.  I think it could be done with only 
one or, at the most, two additional lines.  All core capabilities ought 
to be listed in the man page.

> Now most people I know never read the info pages, because of the
> barrier to entry of the default reader. The required keys to remember
> are quite few really:
>
> http://www.pixelbeat.org/lkdb/info.html
>
> Hmm I wonder could we build and install the html manual on GNU/Linux
> distros at least...

I would prefer that the content of the info pages (in cases where there 
is any content) be moved over to the manual pages, since they are easier 
to work with.  Failing that it would be nicer for the info pages to be 
in HTML 2 so that lynx or another browser could be used.

/Lars

> and then provide this in the man page:
>
> xdg-open
> $(file:///usr/share/doc/coreutils-x.xx/doc/coreutils.html#sort-invocation)
>
>  cheers, Pádraig.





Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 19:38:02 GMT) Full text and rfc822 format available.

Message #27 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Lars Noodén <lars.nooden <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 21:36:45 +0200
On 11/11/11 7:34 PM, Eric Blake wrote:
[snip]
> I'm guessing that there is no bug in sort, but I'll wait for more
> info from you of an actual sample of the lines you want sorted, what
> you tried, what you got, and a comparison to what you wanted, before
> declaring this as not a bug.

There is no bug in sort, it was just that I had to be told explicitly
that sort options could be added to -k as it wasn't so clear from the 
manual page.  An additional line of clarification would go a long way in 
making this very useful capability more available.

/Lars





Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 19:44:02 GMT) Full text and rfc822 format available.

Message #30 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 11:43:33 -0800
On 11/11/2011 11:36 AM, Lars Noodén wrote:
> An additional line of clarification would go a long way in
> making this very useful capability more available.

Hmm, what line would that be?  We do have a tradeoff
among clarity, completeness, and conciseness here.

By the way, the info page (which is the actual documentation
for 'sort' -- the man page is a poor substitute) has a series
of examples, one of which is how to sort Apache log files.
This kind of detail is too long for "sort --help", alas.

http://www.gnu.org/s/coreutils/manual/html_node/sort-invocation.html




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Fri, 11 Nov 2011 19:52:01 GMT) Full text and rfc822 format available.

Message #33 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 10019 <at> debbugs.gnu.org, P <at> draigBrady.com
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Fri, 11 Nov 2011 11:50:56 -0800
On 11/11/2011 09:55 AM, Pádraig Brady wrote:
>   sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
Whew!  That's pretty subtle.  Do you observe
a significant performance improvement by avoiding
-n?  I'm asking partly because the manual does it this way:

  sort -t ' ' -k 4.9n -k 4.5M -k 4.2n -k 4.14,4.21


I find this a bit easier to explain, but if it's significantly
slower we should probably fix the manual.




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Sat, 12 Nov 2011 01:14:01 GMT) Full text and rfc822 format available.

Message #36 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Sat, 12 Nov 2011 01:13:16 +0000
On 11/11/2011 07:50 PM, Paul Eggert wrote:
> On 11/11/2011 09:55 AM, Pádraig Brady wrote:
>>   sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
> Whew!  That's pretty subtle.  Do you observe
> a significant performance improvement by avoiding
> -n?  I'm asking partly because the manual does it this way:
> 
>   sort -t ' ' -k 4.9n -k 4.5M -k 4.2n -k 4.14,4.21
> 
> I find this a bit easier to explain, but if it's significantly
> slower we should probably fix the manual.

I tested that previously and noted only a small performance difference
(I think). So I left the above as more appropriate for the manual.
Testing again on my current hardware shows my version is 33% _slower_
than that in the manual!  I guess explicitly checking the endpoints
of each field is slower than checking implicit sentinels in the data.

cheers,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Sat, 12 Nov 2011 10:51:01 GMT) Full text and rfc822 format available.

Message #39 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Lars Noodén <lars.nooden <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10019 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Sat, 12 Nov 2011 12:49:30 +0200
On 11/11/11 9:43 PM, Paul Eggert wrote:
> On 11/11/2011 11:36 AM, Lars Noodén wrote:
>> An additional line of clarification would go a long way in making
>> this very useful capability more available.
>
> Hmm, what line would that be?  We do have a tradeoff among clarity,
> completeness, and conciseness here.

Maybe something like this?

       -k, --key=POS1[,POS2][ORD]
              start a key at POS1 (origin 1), end it at POS2 (default
	      end  of line) using ordering option(s) ORD (fghMnrR)

> By the way, the info page (which is the actual documentation for
> 'sort' -- the man page is a poor substitute) has a series of
> examples, one of which is how to sort Apache log files. This kind of
> detail is too long for "sort --help", alas.
>
> http://www.gnu.org/s/coreutils/manual/html_node/sort-invocation.html

Yes, that info page is quite complete.  I wish more were like that. 
I've had the bad luck to run into many before that appear to be only 
place holders.

/Lars




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Sat, 12 Nov 2011 13:55:02 GMT) Full text and rfc822 format available.

Message #42 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Lars Noodén <lars.nooden <at> gmail.com>
Cc: 10019 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Sat, 12 Nov 2011 06:54:04 -0700
[Message part 1 (text/plain, inline)]
On 11/12/2011 03:49 AM, Lars Noodén wrote:
> On 11/11/11 9:43 PM, Paul Eggert wrote:
>> On 11/11/2011 11:36 AM, Lars Noodén wrote:
>>> An additional line of clarification would go a long way in making
>>> this very useful capability more available.
>>
>> Hmm, what line would that be?  We do have a tradeoff among clarity,
>> completeness, and conciseness here.
> 
> Maybe something like this?
> 
>        -k, --key=POS1[,POS2][ORD]
>               start a key at POS1 (origin 1), end it at POS2 (default
>           end  of line) using ordering option(s) ORD (fghMnrR)

Except you missed out on at least b and V.  Also, the current wording:

  -k, --key=POS1[,POS2]     start a key at POS1 (origin 1), end it at POS2
                            (default end of line).  See POS syntax below

was nice in referring to the text at the bottom:

POS is F[.C][OPTS], where F is the field number and C the character position
in the field; both are origin 1.  If neither -t nor -b is in effect,
characters
in a field are counted from the beginning of the preceding whitespace.
OPTS is
one or more single-letter ordering options, which override global ordering
options for that key.  If no key is given, use the entire line as the key.

In particular, -k1b,1 is different than -k1,1b, but most other OPTS can
occur in either position with no change in behavior.

I like [OPTS] slightly better than [ORD], given that you can have more
than one (as in -k1bn,1).  I do agree that on the -k line, the use of
"POSn" hides the [.C][OPTS] of the text below, and that it is too easy
to think that POSn is a synonym for just the F. POSIX calls the same
thing 'keydef', so maybe:

  -k --key=KEYDEF  control where a key starts and ends, and give
                   ordering specific to the key. See KEYDEF below.

KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C
a character position in the field; both are origin 1.  If the second
position is omitted, the key runs to the end of the line.  If neither
-t nor -b is in effect, characters in a field are counted from the
beginning of the preceding whitespace.  OPTS is one or more
single-letter ordering options [bdfgiMhnRrV], which override global
ordering options for that key.  If no key is given, use the entire line
as the key.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Sat, 12 Nov 2011 21:31:02 GMT) Full text and rfc822 format available.

Message #45 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10019 <at> debbugs.gnu.org, Lars Noodén <lars.nooden <at> gmail.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Sat, 12 Nov 2011 13:29:35 -0800
On 11/12/11 05:54, Eric Blake wrote:
>   -k --key=KEYDEF  control where a key starts and ends, and give
>                    ordering specific to the key. See KEYDEF below.
>
> KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C
> a character position in the field; both are origin 1.  If the second
> position is omitted, the key runs to the end of the line.  If neither
> -t nor -b is in effect, characters in a field are counted from the
> beginning of the preceding whitespace.  OPTS is one or more
> single-letter ordering options [bdfgiMhnRrV], which override global
> ordering options for that key.  If no key is given, use the entire line
> as the key.

That's nicer, but a bit longer.  How about this attempt to shorten its
first two sentences?

    -k, --key=KEYDEF          sort via a key; KEYDEF gives location and type

  ...

  KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a
  character position in the field; both are origin 1, and the key's end
  defaults to the line's end.

with the remainder as before.





Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Wed, 16 Nov 2011 17:15:02 GMT) Full text and rfc822 format available.

Message #48 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10019 <at> debbugs.gnu.org, Lars Noodén <lars.nooden <at> gmail.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Wed, 16 Nov 2011 10:13:10 -0700
[Message part 1 (text/plain, inline)]
On 11/12/2011 02:29 PM, Paul Eggert wrote:
> On 11/12/11 05:54, Eric Blake wrote:
>>   -k --key=KEYDEF  control where a key starts and ends, and give
>>                    ordering specific to the key. See KEYDEF below.
>>
>> KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C
>> a character position in the field; both are origin 1.  If the second
>> position is omitted, the key runs to the end of the line.  If neither
>> -t nor -b is in effect, characters in a field are counted from the
>> beginning of the preceding whitespace.  OPTS is one or more
>> single-letter ordering options [bdfgiMhnRrV], which override global
>> ordering options for that key.  If no key is given, use the entire line
>> as the key.
> 
> That's nicer, but a bit longer.  How about this attempt to shorten its
> first two sentences?
> 
>     -k, --key=KEYDEF          sort via a key; KEYDEF gives location and type
> 
>   ...
> 
>   KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a
>   character position in the field; both are origin 1, and the key's end
>   defaults to the line's end.
> 
> with the remainder as before.

Sure.  Here's the current state of things in patch format; any last
objections before I push this?

From 968b21312eda99fd5e9402546c370775d1e696cf Mon Sep 17 00:00:00 2001
From: Eric Blake <eblake <at> redhat.com>
Date: Wed, 16 Nov 2011 10:09:12 -0700
Subject: [PATCH] sort: clarify wording on -k syntax
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/sort.c (usage): Use KEYDEF instead of POS, and call out the
specific OPTS that can occur in KEYDEF.
Based on a report by Lars Noodén, http://bugs.gnu.org/10019
---
 src/sort.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/sort.c b/src/sort.c
index 3e94a6e..236cb6a 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -457,8 +457,7 @@ Other options:\n\
                             If F is - then read names from standard
input\n\
 "), stdout);
       fputs (_("\
-  -k, --key=POS1[,POS2]     start a key at POS1 (origin 1), end it at
POS2\n\
-                            (default end of line).  See POS syntax below\n\
+  -k, --key=KEFDEF          sort via a key; KEYDEF gives location and
type\n\
   -m, --merge               merge already sorted files; do not sort\n\
 "), stdout);
       fputs (_("\
@@ -483,13 +482,13 @@ Other options:\n\
       fputs (VERSION_OPTION_DESCRIPTION, stdout);
       fputs (_("\
 \n\
-POS is F[.C][OPTS], where F is the field number and C the character
position\n\
-in the field; both are origin 1.  If neither -t nor -b is in effect,
characters\
-\n\
-in a field are counted from the beginning of the preceding whitespace.
 OPTS is\
-\n\
-one or more single-letter ordering options, which override global
ordering\n\
-options for that key.  If no key is given, use the entire line as the
key.\n\
+KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where
F is a\n\
+field number and C a character position in the field; both are origin
1, and\n\
+the stop position defaults to the line's end.  If neither -t nor -b is
in\n\
+effect, characters in a field are counted from the beginning of the
preceding\n\
+whitespace.  OPTS is one or more single-letter ordering options
[bdfgiMhnRrV],\n\
+which override global ordering options for that key.  If no key is
given, use\n\
+the entire line as the key.\n\
 \n\
 SIZE may be followed by the following multiplicative suffixes:\n\
 "), stdout);
-- 
1.7.7.1



-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Wed, 16 Nov 2011 17:22:02 GMT) Full text and rfc822 format available.

Message #51 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10019 <at> debbugs.gnu.org, Lars, Paul Eggert <eggert <at> cs.ucla.edu>,
	Noodén <lars.nooden <at> gmail.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Wed, 16 Nov 2011 18:21:08 +0100
Eric Blake wrote:
> Sure.  Here's the current state of things in patch format; any last
> objections before I push this?
...
> Subject: [PATCH] sort: clarify wording on -k syntax
>
> * src/sort.c (usage): Use KEYDEF instead of POS, and call out the
> specific OPTS that can occur in KEYDEF.
> Based on a report by Lars Noodén, http://bugs.gnu.org/10019
...
> +KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where
> F is a\n\
> +field number and C a character position in the field; both are origin
> 1, and\n\
> +the stop position defaults to the line's end.  If neither -t nor -b is
> in\n\
> +effect, characters in a field are counted from the beginning of the
> preceding\n\
> +whitespace.  OPTS is one or more single-letter ordering options
> [bdfgiMhnRrV],\n\
> +which override global ordering options for that key.  If no key is
> given, use\n\
> +the entire line as the key.\n\

Thanks.  That reads well.
Note that some tool of yours appears to have split many lines of that patch.




Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Wed, 16 Nov 2011 19:55:02 GMT) Full text and rfc822 format available.

Message #54 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
Cc: 10019 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Lars Noodén <lars.nooden <at> gmail.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Wed, 16 Nov 2011 11:21:28 -0700
[Message part 1 (text/plain, inline)]
On 11/12/2011 06:54 AM, Eric Blake wrote:
> POS is F[.C][OPTS], where F is the field number and C the character position
> in the field; both are origin 1.  If neither -t nor -b is in effect,
> characters
> in a field are counted from the beginning of the preceding whitespace.
> OPTS is
> one or more single-letter ordering options, which override global ordering
> options for that key.  If no key is given, use the entire line as the key.
> 
> In particular, -k1b,1 is different than -k1,1b, but most other OPTS can
> occur in either position with no change in behavior.
> 
> I like [OPTS] slightly better than [ORD], given that you can have more
> than one (as in -k1bn,1).

In fact, this thread prompted me to file a bug against POSIX, where a
strict reading of the existing text says that portable clients cannot
use more than one OPT simultaneously, even though all implementations
that I tried support that usage.

http://austingroupbugs.net/view.php?id=510

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Wed, 16 Nov 2011 20:30:02 GMT) Full text and rfc822 format available.

Message #57 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 10019 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	Lars Noodén <lars.nooden <at> gmail.com>
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Wed, 16 Nov 2011 10:27:38 -0700
[Message part 1 (text/plain, inline)]
On 11/16/2011 10:21 AM, Jim Meyering wrote:
> Eric Blake wrote:
>> Sure.  Here's the current state of things in patch format; any last
>> objections before I push this?
> ...
>> Subject: [PATCH] sort: clarify wording on -k syntax
>>
>> * src/sort.c (usage): Use KEYDEF instead of POS, and call out the
>> specific OPTS that can occur in KEYDEF.
>> Based on a report by Lars Noodén, http://bugs.gnu.org/10019
> ...
>> +KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where
>> F is a\n\
>> +field number and C a character position in the field; both are origin
>> 1, and\n\
>> +the stop position defaults to the line's end.  If neither -t nor -b is
>> in\n\
>> +effect, characters in a field are counted from the beginning of the
>> preceding\n\
>> +whitespace.  OPTS is one or more single-letter ordering options
>> [bdfgiMhnRrV],\n\
>> +which override global ordering options for that key.  If no key is
>> given, use\n\
>> +the entire line as the key.\n\
> 
> Thanks.  That reads well.

Pushed.

> Note that some tool of yours appears to have split many lines of that patch.

That's what I get for pasting into a Thunderbird compose window, instead
of sending as an attachment.  Obviously, the patch itself is not line
split that badly.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#10019; Package coreutils. (Wed, 16 Nov 2011 23:29:01 GMT) Full text and rfc822 format available.

Message #60 received at 10019 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10019 <at> debbugs.gnu.org
Subject: Re: bug#10019: sort options -Mn are incompatible
Date: Wed, 16 Nov 2011 15:27:41 -0800
On 11/16/11 09:27, Eric Blake wrote:
> That's what I get for pasting into a Thunderbird compose window

Here's how to shut that annoying feature off:

http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Flowed_format




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 15 Dec 2011 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 107 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.