[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

not a bug [Re: Bug in sort

From: Jim Meyering
Subject: not a bug [Re: Bug in sort
Date: Sat, 12 Jan 2002 10:09:47 +0100
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.50 (i686-pc-linux-gnu)

You wrote:
[...sort -M doesn't work the way I expect it to...]

Thanks for the report, but that's not due to a bug.

Two things might be causing trouble here:

  - a common misunderstanding about how sort works with byte offsets:
      without `-b' or the b attribute, each field includes leading delimiters
  - a subtlety in the rules for determining whether global attributes affect
      key specs

Use this in examples below

  $ cat in
  x Jun
  a Jan
  b Dec

You reported that this doesn't work:

  $ sort -k2.1,2.3M in
  a Jan
  b Dec
  x Jun

Now that you know about -b,
(aka --ignore-leading-blanks, if you're using textutils-2.0.14 or newer)
you might try this:

  $ sort -b -k2.1,2.3M in
  a Jan
  b Dec
  x Jun

but as you can see above, that doesn't work either.
The following, with a local `b' attribute appended, doesn't work either:

  $ sort -k2.1,2.3Mb in
  a Jan
  b Dec
  x Jun

But the following *does* work, with the `b' attribute applied to
the starting position:

  $ sort -k2.1b,2.3M in
  a Jan
  x Jun
  b Dec

Applying `b' to the starting position makes sort remove *leading* delimiters.

The second example highlights a subtlety in how global attributes (from
options like -b) are `inherited' (or not) by individual `key specs'.
A global attribute is inherited by a key spec IFF that key spec has no
local modifiers.  In the example above, there is a local `M' modifier,
so the global -b had no effect on that key spec.  Another way to make
this simple example work properly is to use only global attributes:

  $ sort -bM -k 2.1b,2.3 in
  a Jan
  b Dec
  x Jun

Note that on some older systems, your example would have worked
just fine.  E.g. Solaris5.5.1's /bin/sort -M strips leading blanks,
while Solaris 8's /bin/sort -M does not.

Here's a note from the documentation `info sort':

     Historical (BSD and System V) implementations of `sort' have
  differed in their interpretation of some options, particularly `-b',
  `-f', and `-n'.  GNU sort follows the POSIX behavior, which is usually
  (but not always!) like the System V behavior.  According to POSIX, `-n'
  no longer implies `-b'.  For consistency, `-M' has been changed in the
  same way.  This may affect the meaning of character positions in field
  specifications in obscure cases.  The only fix is to add an explicit

reply via email to

[Prev in Thread] Current Thread [Next in Thread]