Bug 64226 - Sort creates wrong order if sorting multiple fields
Summary: Sort creates wrong order if sorting multiple fields
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: textutils (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-29 18:50 UTC by Fedor Pikus
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-09-26 02:03:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Fedor Pikus 2002-04-29 18:50:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020311

Description of problem:
Rus this:
( echo '/  e' ; echo '/b e' ) | sort
/b e
/  e

Now run this:
( echo '/  e' ; echo '/b e' ) | sort -k 1,1
/  e
/b e

I think the first one is wrong: sort should look at the first field, then second
field if needed. In this case second field is not needed, first field "/" should
go before "/b" and that's enough for sorting.
Instead, sort somehow merges the fields and sorts on the "b before e" order: if
I say instead
 ( echo '/  a' ; echo '/b a' ) | sort
then the order is correct,
/  a
/b a
but for the wrong reason, it sorts this way because "a before b", should be
because "/ before /b".

Here is where the problem comes out: autofs4 creates /net mounts by
sorting output of showmount. Typical output looks something like this:
/    (everyone)
/a   (everyone)
Since a < e, sorted order is /a first. autofs4 creates a strange infinite loop
of mounts when /a is mounted before /.

Version-Release number of selected component (if applicable):
rpm -q textutils

How reproducible:

Steps to Reproduce:
1.( echo '/  e' ; echo '/b e' ) | sort - BAD
2.( echo '/  e' ; echo '/a e' ) | sort -k 1,1 - GOOD

Additional info:

Comment 1 Bill Hees 2002-08-07 21:37:13 UTC
This 'multiple fields' bug is likely caused by the fact that if LC_COLLATE is
undefined (and that's the default configuration it seems) sort ignores spaces. 
This came up in bug 17204 too.

I've found 'default' sort also ignores hyphens.  The following text is
considered sorted:

x 30
x -4
x 50

Seems pretty wrong IMO.  I couldn't find a Posix spec for what should happen
when LC_COLLATE is undefined.  If it's up to the implementer it would seem
defaulting to C-style would be safer than the current approach.

-Bill Hees

Comment 2 Tim Waugh 2002-10-07 11:23:19 UTC
'Undefined'?  What exactly is LC_COLLATE in your example?  Not C, I'll be 

Note You need to log in before you can comment on or make changes to this bug.