Re: sort command - on RED HAT LINUX 6.2

[Bob Proulx]

> I'm not sure if this is a BUG or not but if I use the sort command 'sort
> sortbefore -o sortafter' on the file below. It seems to by default ignore

Your report matches a common pattern.  Jim has previously answered
these reports with the following mail.  Note that some vendors set
those language variables for you without you being aware of them.  If
you consider that a bug then submit it to your vendor.

> Is it something to do with the LC_COLLATE setting?

Yes.  Or one of the related variables.  check out the online standards
documentation for a complete list.

  http://www.unix-systems.org/single_unix_specification_v2/
  http://www.unix-systems.org/single_unix_specification_v2/xcu/sort.html

It is likely that your vendor set LANG=en_US in your environment
without you knowing about it.  You can find those by grep'ing them
from your environment.

  env | grep en_US

Bob

========================================================================

Jim Meyering writes:

Thanks for the report.
Here's the canned reply:
------------

You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.

That is due not to a bug in sort, but to the fact that you have
set environment variables that direct sort to use improper locale-
specific tables (you or your vendor have probably set environment
variables like LANG, LC_ALL, or LANGUAGE to en_US).

Unset them, and then set LC_ALL to POSIX

  # If you use bash or some other Bourne-based shell,
  export LC_ALL=POSIX

  # If you use a C-shell,
  setenv LC_ALL POSIX

and sort will then work the way you expect.
-----------

BTW, in recent textutils test releases, sort --help output
includes this:

  *** WARNING ***
  This version of sort honors the locale settings in your environment.
  For example, if you set one of the LANG or LC_ALL environment variables
  to `en_US', then sort will work very differently than most people expect.
  If that's not what you want, then set LC_ALL to POSIX in your environment.

> the leading spaces and ends up using the first non space character, accrding
> to the manual it should remain unsorted.
> A pair of lines is compared as follows: if any key fields have been
> specified, sort compares each pair of fields, in the order specified on the
> command line, according to the associated ordering options, until a
> difference is found or no fields are left. Unless otherwise specified, all
> comparisons use the character collating sequence specified by the LC_COLLATE
> locale. 
> 
> sortbefore:
>            0 00000001 NNNNNN000001000001
>          76 00000002 NNNNNN000001000001
>         152 00000003 NNNNNN000001000001
>         228 00000004 NNNNNN000001000001
>         304 00000005 NNNNNN000001000001
>         380 00000006 NNNNNN000001000001
>         456 00000007 NNNNNN000001000001
>         532 00000008 NNNNNN000001000001
>         608 00000009 NNNNNN000001000001
>         684 00000010 NNNNNN000001000001
>         760 00000011 NNNNNN000001000001
>         836 00000012 NNNNNN000001000001
>         912 00000013 NNNNNN000001000001
>         988 00000014 NNNNNN000001000001
>        1064 00000015 NNNNNN000001000001
> 
> sortafter:
>           0 00000001 NNNNNN000001000001
>        1064 00000015 NNNNNN000001000001
>         152 00000003 NNNNNN000001000001
>         228 00000004 NNNNNN000001000001
>         304 00000005 NNNNNN000001000001
>         380 00000006 NNNNNN000001000001
>         456 00000007 NNNNNN000001000001
>         532 00000008 NNNNNN000001000001
>         608 00000009 NNNNNN000001000001
>         684 00000010 NNNNNN000001000001
>         760 00000011 NNNNNN000001000001
>          76 00000002 NNNNNN000001000001
>         836 00000012 NNNNNN000001000001
>         912 00000013 NNNNNN000001000001
>         988 00000014 NNNNNN000001000001
> 
> 
> I would have expect the sortbefore & sortafter files to be the same, as is
> the case on other flavours of UNIX (DEC & SUN).  Using sort -n gives me the
> expected results for this file but other files may not necessarily contain
> numeric values and be a mixture of numeric and non-numeric values.
> 
> Is it something to do with the LC_COLLATE setting?
> 
> Thanking you in advance.
> 
> Kevin Knowlden