Bug 36857 - Broken ordering when running grep -l with bash
Broken ordering when running grep -l with bash
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-20 12:45 EDT by Thierry Valentin
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-20 12:45:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thierry Valentin 2001-04-20 12:45:26 EDT
Hello,
I got a strange bug while using grep with bash on Redhat 7.0:
'grep -l pattern files' does not list matching files in the same order
as ls -1 !!! I don't know what the problem is related to grep? bash?
sort?

Example:
I have a directory containing files a.cc, a1.cc, b.cc, and b2.cc
that all contain the text "hello"

-- Running 'ls -1 *.cc' gives:
a.cc
a1.cc
b.cc
b2.cc

which is the correct lexicographic order

-- Running 'grep -l hello *.cc' gives:
a1.cc
a.cc
b2.cc
b.cc

THE ORDER IS NOT PRESERVED!!!
This problem is very annoying because the following commands:

grep -l hello *.cc > cc_files_containing_hello
ls *.cc | comm -23 - cc_files_containing_hello > \
    cc_files_not_containing_hello

which extract the list of files that do not contain pattern "hello"
will not work, because the file order in cc_files_containing_hello is
not the same as the one used by ls.

It is even more annoying because it was working on Redhat 6.0!

One thing that is surprising is that the problem does not occur
when I'm running the same commands under pdksh-5.2.14-8 !!!

Summary of the tests:

The problem occurs on
- Redhat 7.0 when running grep-2.4.2-4 under bash-2.04-11

Everything works fine on:
- Redhat 7.0 when running grep-2.4.2-4 under pdksh-5.2.14-8
- Redhat 6.0 when running grep-2.3-2 with under bash-1.14.7-16
- Redhat 6.0 when running grep-2.3-2 with under pdksh-5.2.14-1
- IRIX 6.x
- Solaris *
- HP-UX 10.20


Related problem (?)

Because I had some doubts about what Linux considers to be a lexicographic
order, I ran the following command on several Unix platforms:

ls -1 *.cc | sort

IRIX 6.x, Solaris 2.x and  HP-UX 10.20 returned the correctly
sorted result:

a.cc
a1.cc
b.cc
b2.cc

Redhat 6.0 and Redhat 7.0 (gnu sort) returned the following
incorrect result (not a lexicographic order, thus incompatible
with ls! ):

a1.cc
a.cc
b2.cc
b.cc

There may be some relation ship with my problem here (?)

Is there a patch that fixes the problem?
Thanks for your help.
Comment 1 Bernhard Rosenkraenzer 2001-04-20 19:03:00 EDT
This is a feature, not a bug.
bash 2.x is locale aware, and sorts according to the locale, not according to 
what C thinks, therefore a1 can come before a.

(*.cc is expanded by bash, put in the right order according to your locale, 
then passed to grep, which preserves the order dictated by bash).

If you don't like this,

export LC_COLLATE=C

or

grep -l hello `ls -1 *.cc`

The latter may change to do just what you're seeing now in a later version of 
fileutils.

Comment 2 Thierry Valentin 2001-04-23 04:36:15 EDT
export LC_COLLATE=c makes things work as expected.
Thanks a lot for your help

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