From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020311
Description of problem:
( echo '/ e' ; echo '/b e' ) | sort
Now run this:
( echo '/ e' ; echo '/b e' ) | sort -k 1,1
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,
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:
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
Steps to Reproduce:
1.( echo '/ e' ; echo '/b e' ) | sort - BAD
2.( echo '/ e' ; echo '/a e' ) | sort -k 1,1 - GOOD
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
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.
'Undefined'? What exactly is LC_COLLATE in your example? Not C, I'll be