Bug 43880

Summary: ls does not use punctuation when sorting
Product: [Retired] Red Hat Linux Reporter: Bill Lee <billl>
Component: fileutilsAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: martin, rwmoore
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: 2001-06-27 00:56:17 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:
Attachments:
Description Flags
RPM with fixed 'ls' command none

Description Bill Lee 2001-06-07 18:18:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3.msu i686)

Description of problem:
When I use ls, it does not include the punctuation in its sort.  Ls will
show the following three files as:

file.c filemake.c file.o

Previous versions of ls give 

file.c  file.o  filemake.c


How reproducible:
Always

Steps to Reproduce:
1. touch file.c file.o filemake.c
2. ls
3.
	

Actual Results:  file.c filemake.c file.o

Expected Results:  file.c  file.o  filemake.c

Additional info:

could not find an option to change the sort

Comment 1 Martin Richek 2001-06-11 23:52:05 UTC
This is even more obvious with "ls -a" in a directory with both hidden and non-
hidden files. The hidden (or dot) files should all precede the non-hidden 
files, but, in fact, they are sorted as if the leading dot were not present.

Comment 2 Roger Moore 2001-06-21 19:24:03 UTC
You can fix this by replacing all the references to 'strcoll' with strcmp.
This returns 'ls' to the default behaviour. It seems that the locale 
configuration is broken but I don't know how to fix this myself so this is
a viable workaround.


Comment 3 Roger Moore 2001-06-21 19:26:26 UTC
Created attachment 21485 [details]
RPM with fixed 'ls' command

Comment 4 Bernhard Rosenkraenzer 2001-06-26 16:44:09 UTC
locale-awareness can hardly be considered a bug.
If you don't like it,
export LC_COLLATE=C


Comment 5 Martin Richek 2001-06-26 17:34:40 UTC
LC_COLLATE=C DOES NOT FIX THIS PROBLEM!


Comment 6 Martin Richek 2001-06-26 17:38:28 UTC
OOPS! Sorry about that. LC_COLLATE=C does fix the problem.

Thank you.

Comment 7 Roger Moore 2001-06-26 18:41:08 UTC
Locale awareness IS a bug if it doesn't order things correctly. File names are 
not required to be words in any language. The sorting order of filenames is 
not neccessarily the same as words for the English (or other) language. This 
is an inappropriate place to use locale sorting.

I have no objection to using locale based sorts for the appropriate items or, 
to stretch a point, even with 'ls': PROVIDED IT MAINTAINS THE STANDARD SORTING 
ORDER. This does not and therefore this is a bug, we should not have to set 
environment variables to make 'ls' behave correctly. Not only that but I 
presume this fix stops locale sorts working where you actually want it to work?

This should be fixed: it is a bug!



Comment 8 Bill Lee 2001-06-27 00:56:12 UTC
It is not locale awareness that is the problem.  The problem is that the 'ls'
command, one of the most basic commands in unix and linux no longer functions as
it always has in the past.

I don't mind if a new flag is added to 'ls' to enable locale awareness sorting,
but to remove it, one should not have to include a flag or set an environmental
variable.

When I place punctuation in the middle of my file names, it should be assumed
that I wanted to put it there, so this punctuation should not be arbitrarily
removed from the sort.

Comment 9 Bernhard Rosenkraenzer 2001-06-27 11:17:27 UTC
Then export LC_COLLATE=C
The current behavior is the way the fileutils maintainers and POSIX want it.
Yes, this is not the way traditional ls worked, and I don't really like it 
either (my initial fix was to make locale sorting optional, introducing a new 
flag needed to activate it, but I got overruled).