sort result different on 2 servers.

Hi, all:

The sort result is different on 2 servers. One of them seems to be
wrong.

There are 2 Linux servers in our office. Both are the same model.
Processor: AMD Dual core 2218
Machine: Tyan GT24/3392

One server (Let's call it server A now) has to be accessed from a
Solaris machine by using qrsh -q . The Solaris machine is
accessed through a Windows software Cygwin.

The other server (Let's call it server B now.) can be opened directly
using Cygwin from my Windows system.

The sort command is identical on the 2 Linux servers. Both look like
below:
# which sort
/bin/sort
# cksum /bin/sort
1931310628 54216 /bin/sort

Let's use the same raw file to see their sort result on each server.
# cksum sort_raw
2042083065 520 sort_raw

The file sort_raw looks like below:
AA.12 10177
SN.17l 15198
AA.15a 93
AA.16a 1
TOUCH 12
AA.17 868
AA.19 2
SP.16l 4920
AA.1l_AA.2l 63
AA.3 29999
AREA 3
SN.11 517
SN.1 2130
SN.16l 9460
SN.2 23
SN.3 4314
SP.1 41
SP.17l 20244

The result is expected to be the same on each server. However, it
happens to be different.

On server A,
.... ...
SN.11 517
SN.1 2130
.... ...

On server B,
.... ...
SN.1 2130
SN.11 517
.... ...

The result on server A seems to be wrong. Is there a bug on server A?
Is there any environment setting that could affect this? What's
perhaps the reason of this bug? Is there any solution of the fix?

Detail data see below.

Thanks.

- - - -

On server A:
# sort sort_raw
sort_raw
AA.12 10177
AA.15a 93
AA.16a 1
AA.17 868
AA.19 2
AA.1l_AA.2l 63
AA.3 29999
AREA 3
SN.11 517
SN.1 2130
SN.16l 9460
SN.17l 15198
SN.2 23
SN.3 4314
SP.1 41
SP.16l 4920
SP.17l 20244
TOUCH 12

On server B:
# sort sort_raw
sort_raw
AA.12 10177
AA.15a 93
AA.16a 1
AA.17 868
AA.19 2
AA.1l_AA.2l 63
AA.3 29999
AREA 3
SN.1 2130
SN.11 517
SN.16l 9460
SN.17l 15198
SN.2 23
SN.3 4314
SP.1 41
SP.16l 4920
SP.17l 20244
TOUCH 12

On Thursday 28 August 2008 13:35, Kuhl wrote:

> The result on server A seems to be wrong. Is there a bug on server A?
> Is there any environment setting that could affect this? What's
> perhaps the reason of this bug? Is there any solution of the fix?

Try using the same locale settings for both environment, eg

LC_ALL=C sort ...

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Hi, Setting the environment variable LC_ALL=C works. But it's still
confusing.

1. I checked both the 2 servers. Before I set this variable, it's
defined in NONE of the two environments. They are using the same sort
binary file, and none of them have LC_ALL defined before. Why were
their results different? It seems LC_ALL affects the sort result on
one server, while LC_ALL is no use on the other server.

2. My sort manual page says: "set LC_ALL=C to get the traditional sort
order that uses native byte values." Then what is the sort order
supposed to be if we don't set this variable?

Thanks.

On Friday 29 August 2008 15:43, Kuhl wrote:

> Hi, Setting the environment variable LC_ALL=C works. But it's still
> confusing.
>
> 1. I checked both the 2 servers. Before I set this variable, it's
> defined in NONE of the two environments. They are using the same sort
> binary file, and none of them have LC_ALL defined before. Why were
> their results different? It seems LC_ALL affects the sort result on
> one server, while LC_ALL is no use on the other server.
>
> 2. My sort manual page says: "set LC_ALL=C to get the traditional sort
> order that uses native byte values." Then what is the sort order
> supposed to be if we don't set this variable?

If LC_ALL is unset, then I guess that each locale-aware program (like sort)
will try to use other relevant locale variables like LC_COLLATE, if they
are set.

If no locale varible is set, then I don't know what the results could be
(unspecified?). Maybe someone else can provide more information.

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.

Hi, I checked the variable settings in both environments. Both are
like below.

# echo $LC_COLLATE
LC_COLLATE: Undefined variable.

# echo $LC_MESSAGES
LC_MESSAGES: Undefined variable.

# echo $LC_NUMERIC
LC_NUMERIC: Undefined variable.

# echo $LC_ALL
LC_ALL: Undefined variable.

# echo $LC_CTYPE
LC_CTYPE: Undefined variable.

# echo $NLSPATH
NLSPATH: Undefined variable.

But it makes sense that they have different result if sort is working
in an unspecified condition. However, I need to guarantee that I set
LC_ALL to be C everytime I use sort in the future.

Thanks.

On Sat, 30 Aug 2008 06:09:27 -0700, Kuhl wrote:

> Hi, I checked the variable settings in both environments. Both are like
> below.
>
> # echo $LC_COLLATE
> LC_COLLATE: Undefined variable.
>
> # echo $LC_MESSAGES
> LC_MESSAGES: Undefined variable.
>
> # echo $LC_NUMERIC
> LC_NUMERIC: Undefined variable.
>
> # echo $LC_ALL
> LC_ALL: Undefined variable.
>
> # echo $LC_CTYPE
> LC_CTYPE: Undefined variable.
>
> # echo $NLSPATH
> NLSPATH: Undefined variable.
>
> But it makes sense that they have different result if sort is working in
> an unspecified condition. However, I need to guarantee that I set LC_ALL
> to be C everytime I use sort in the future.
>
> Thanks.

What does the "locale" command say on these machines?

It appears that each locale-aware Linux application will have its own
idea of what its default locale (sort, sed, python, perl, whatever)
should be when these variables aren't set - often C or en_US, and some
will have it in a file somewhere, while others will have it compiled in.
There also appears to be a locale for pathnames.

There's a system default locale on some/many systems, but setting that
appears to be highly platform-specific.