Bug 127354 - join does not produce correct output
Summary: join does not produce correct output
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: coreutils   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2004-07-06 23:54 UTC by Brian Ferguson
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: RHBA-2005-544
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 17:01:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A sample data file (4.13 KB, text/plain)
2004-07-12 20:02 UTC, Brian Ferguson
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:544 qe-ready SHIPPED_LIVE coreutils bug fix update 2005-09-28 04:00:00 UTC

Description Brian Ferguson 2004-07-06 23:54:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040615 Firefox/0.9

Description of problem:
I have a scientific program that uses the 'join' program extensively,
in some rather odd ways.  In particular there is one part where it
issues the following command:

join -v 1 -o 1.2 data_file empty_file

which is supposed to grab the second column of text in standard input.
 However with the version of join in coreutils-4.5.3-26, it produces
an empty file with carriage returns instead of lines of text.  With
earlier versions of join (from textutils-2.0.21-1), or with
coreutils-5.2.1 from gnu.org this bug does not exist.

Sample data file:

empty_file is just an empty file, /dev/null would suffice.
On RH7.3, textutils-2.0.21-1 and RHEL 3, coreutils-5.2.1(gnu.org):
bash-2.05b$ join -v 1 -o 1.2 data_file empty_file
On RHEL coreutils-4.5.3-26:
bash-2.05b$ join -v 1 -o 1.2 tmp_sort /dev/null
However if I do:
bash-2.05b$ join -v 1 -o 1.3 tmp_sort /dev/null
It produces the correct output.
So it looks like this bug involves using whitespace space as a
delimiter.  Small text files of random junk with a space between the
fields do not exhibit this bug though.

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

How reproducible:

Steps to Reproduce:
1. Create a file that contains "fsh_110703_1_0351310_0351890 
2. Run join -v 1 -o 1.2 filename /dev/null

Actual Results:  It outputs a single carriage return.

Expected Results:  It should output the second column of data.  With
small amounts of text in the sample file this *does* work properly.

Additional info:

Comment 1 Tim Waugh 2004-07-07 12:53:44 UTC
Please attach your example data file so that I can be sure that I'm
looking at the same problem here.  Bugzilla has line-wrapped your
comment and I can't be sure I'm looking at the same bytes.

Comment 2 Brian Ferguson 2004-07-12 20:02:16 UTC
Created attachment 101824 [details]
A sample data file

join -v 1 -o 1.2 data_file /dev/null

produces blank lines of text.

Comment 3 Brian Ferguson 2004-07-12 20:04:36 UTC
I just noticed the produced data file has two spaces between the
fields.  Still, join 4.5.3 in RHEL does perform differently from join
in RH 7.3 and join downloaded from gnu.org.

Comment 4 Tim Waugh 2004-07-13 09:48:54 UTC
Okay, it is certainly the same issue I was looking at then.  I have
fixed this issue in our internal source repository, and the fix will
be included in any future coreutils update for Red Hat Enterprise
Linux 3.  (Fedora Core is not affected.)

Thanks for the report.

Comment 5 Brian Ferguson 2004-10-15 22:54:38 UTC
Any news on when can we expect a new version of coreutils that fixes
this bug?

Comment 6 Tim Waugh 2004-10-19 11:39:13 UTC
There is no coreutils update for Red Hat Enterprise Linux 3 currently planned.

Comment 14 Red Hat Bugzilla 2005-09-28 17:01:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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