Bug 64226

Summary: Sort creates wrong order if sorting multiple fields
Product: [Retired] Red Hat Linux Reporter: Fedor Pikus <pikus>
Component: textutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-09-26 02:03:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
result:
/b e
/  e

Now run this:
( echo '/  e' ; echo '/b e' ) | sort -k 1,1
result:
/  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
textutils-2.0.14-2

How reproducible:
Always

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

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 
bound.