bug#7878: "sort" bug--inconsistent single-column sorting influenced by other columns?

[Randall Lewis]

Thanks Paul.

Yes, it would seem that the true solution to my problem is doing the following 
(as you suggested):

use "sort -k 1,1 -t '|'"

This ensures that I sort on the first field--whereas "sort -k1 -t '|'" does 
not, as much as I wanted it to. ;) Since I was joining on only the first field 
I should've only been sorting on the first field. So, perhaps the only logical 
conflict with my usage here is that "join" works on the first field by default 
(as far as I can tell from join --help) while "sort" does not. But I guess this 
makes sense since "sort" is used for much more (bizarre use cases) than just as 
a pre-step to "join."

I'll read up on the coreutils manual next time.

Thanks for being patient with me and for the great feedback. :)

--Randall


-----Original Message-----
From: Paul Eggert [mailto:address@hidden 
Sent: Friday, January 21, 2011 1:26 AM
To: Randall Lewis
Cc: address@hidden
Subject: Re: bug#7878: "sort" bug--inconsistent single-column sorting 
influenced by other columns?

On 01/20/2011 11:29 PM, Randall Lewis wrote:
> Also, who would've thought that the default "sort" would be incompatible with 
> "join" and that you would need to write the command like this every time you 
> wanted to use "join"?
> 
> LC_ALL=C sort test1.txt

No, "sort" and "join" use the same collating sequence by default.

It sounds like you have a different problem: you
weren't sorting by the same field that you were
joining on.  For example, if you want to use plain
"join" then you need to sort via "sort -k 1b,1".
Or, if you want to use "join -t '|'" then you
also need to use "sort -k 1,1 -t '|'".

This is documented in the coreutils manual.

It may be that "LC_ALL=C sort" worked around your
problem on your particular test case, but it won't
work in general.