s
Michael
--
From: "Paul Eggert"
Sent: Wednesday, October 17, 2012 11:14 PM
To: "Michael"
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug report!
On 10/17/2012 12:19 AM, Michael wrote:
# sort -n file1 > file3
# sort -n file2 > file4
# join f
Paul Eggert wrote:
> On 10/17/2012 12:19 AM, Michael wrote:
> > # sort -n file1 > file3
> > # sort -n file2 > file4
> >
> > # join file3 file4
>
> That won't work. You have to join with the same
> sorting order that you sorted with. This is discussed
> in the manual.
Since this seems to have b
On 10/17/2012 12:19 AM, Michael wrote:
> # sort -n file1 > file3
> # sort -n file2 > file4
>
> # join file3 file4
That won't work. You have to join with the same
sorting order that you sorted with. This is discussed
in the manual.
on '-n', the result after joining was correct.
Michael
--
From: "Paul Eggert"
Sent: Wednesday, October 17, 2012 12:10 AM
To: "Michael"
Cc: <12...@debbugs.gnu.org>
Subject: Re: bug#12659: the join command bug rep
Sounds like a locale problem. What does the "locale"
command say? How exactly are you invoking 'sort' and
'join'? What do the input and output lines look like?
Hi,
I have two sorted files with million of lines to join together, I am sure of
that there are at least 1/3 keys in two files are the same, but no even one key
joined together. there's no such situation within small files.
Michael Wu
forcemerge 12264 6366
stop
On 08/23/2012 07:08 AM, Szilard Albert wrote:
> Hi,
>
> I am trying to use the join command to join the below files, and it only
> works for up to the pair of 1000.
> Any suggestions?
join(1) doesn't support numeric comparison currently.
It should
Hi,
I am trying to use the join command to join the below files, and it only
works for up to the pair of 1000.
Any suggestions?
cheers
Sid
900-164.06
901-164.05
902-164.03
903-164.02
904-164.01
905-163.99
906-163.98
Pádraig Brady wrote:
...
> Thanks for looking into that Alan, and thanks for reporting this Jean-Pierre.
> I've installed the attached to document the fix and add a test.
...
> Subject: [PATCH] tests: add a test for a previously fixed output format bug
> in join
>
> Add a test and NEWS entry for a
On 07/22/2012 12:22 AM, Alan Curry wrote:
> Eric Blake writes:
>>
>> On 07/21/2012 12:20 PM, Jean-Pierre Tosoni wrote:
>>> Hello Maintainer,
>>> =20
>>> I am using join v8.5 from debian squeeze.
>>> =20
>>
>>> now, the command:
>>>join -v 2 -1 2 -2 3 a b
>>> produces
>>> =3D=3D=3D=3D
Hello again,
I investigated against various sources at gnu.org.
The bug exists at least in versions 8.5 to 8.9, and was corrected in
version 8.10, probably by chance during implementation of output formatting
extensions.
Hence the problem comes from debian-squeeze using an old release, and this
i
Eric Blake writes:
>
> On 07/21/2012 12:20 PM, Jean-Pierre Tosoni wrote:
> > Hello Maintainer,
> >=20
> > I am using join v8.5 from debian squeeze.
> >=20
>
> > now, the command:
> >join -v 2 -1 2 -2 3 a b
> > produces
> > =3D=3D=3D=3D wrong output =3D=3D=3D=3D
> > zzz222 zzz111 key
tag 12019 moreinfo
thanks
On 07/21/2012 12:20 PM, Jean-Pierre Tosoni wrote:
> Hello Maintainer,
>
> I am using join v8.5 from debian squeeze.
>
> now, the command:
>join -v 2 -1 2 -2 3 a b
> produces
> wrong output
> zzz222 zzz111 keyZ zzz333
I tried reproducing this wi
Hello Maintainer,
I am using join v8.5 from debian squeeze.
When using the -v2 option with different join fields in files 1 and 2, the
join field which gets moved to the beginning of the result lines is the one
identified by the -1 option, not the one identified by the -2 option.
Here are my te
okay the problem is over,
i have found my error: join command need to have files with a common field
sorted with alphanumerical order and not numerical order (sort -n).
James Youngman a écrit :
On Wed, Feb 25, 2009 at 8:20 PM, Laurent Manchon
wrote:
-- Hi,
i have used a join command as
gt; but .zip tends to be used in propagating viruses, so I won't guarantee
> whether it can make it through unscathed.
Laurent should have replied to the list
that he had found his issue.
"okay the problem is over,
i have found my error: join command need to have files with a comm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 2/26/2009 6:12 AM:
> According to Laurent Manchon on 2/25/2009 1:20 PM:
>> -- Hi,
>
>> with the files i send you in attachment(files.zip).
>
> It's likely that your files aren't properly sorted. While I didn't
> validate y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Laurent Manchon on 2/25/2009 1:20 PM:
> -- Hi,
>
> i have used a join command as: "join -1 1 -2 1 -o
> 2.1,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9 file.test V.test"
> with the files i send you in attachment(files.zip
On Wed, Feb 25, 2009 at 8:20 PM, Laurent Manchon
wrote:
> -- Hi,
>
> i have used a join command as: "join -1 1 -2 1 -o
> 2.1,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9 file.test V.test"
> with the files i send you in attachment(files.zip).
> This command returns only 55 lin
-- Hi,
i have used a join command as: "join -1 1 -2 1 -o
2.1,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9 file.test V.test"
with the files i send you in attachment(files.zip).
This command returns only 55 lines.
The real number in the output must be 1031 lines.
What's wro
that
encountered exactly the same problem as me (mail in Apr 2008) and
received the following answer from Bob:
kevin wrote:
> I want to use join command with this 2 files :
> test1:
> 1 a
> 2 a
> 3 a
> 45 a
> 78 a
> 152 a
> 1896 a
The input files to join must be sorted
st tell us you have two vast inputs you
won't show us that don't join in the way you expect.
> When I perform a very simple join command as follows:
>
> Join -1 2 -2 2 file1.txt file2.txt > joinedfile.txt
>
>
> I obtain a joinedfile of ~213.000 lines in place of the
G A 0.3856289880
...
The first file is ~ 1,400,000 lines long
The second file is ~ 330,000 lines long
There should be ~322,000 lines in common (i.e., with the same SNP
identifier - field #2).
When I perform a very simple join command as follows:
Join -1 2 -2 2 file1
kevin wrote:
> I want to use join command with this 2 files :
> test1:
> 1 a
> 2 a
> 3 a
> 45 a
> 78 a
> 152 a
> 1896 a
The input files to join must be sorted. The above is not.
Please see this reference for more information.
http://www.gnu.org/software/coreu
I forget to give you the version of coreutils :
5.97-5.3ubuntu3
Thanks for your help
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
I want to use join command with this 2 files :
test1:
1 a
2 a
3 a
45 a
78 a
152 a
1896 a
test2:
1 a
2 a
3 a
152 a
1896 a
When i do : join test1 test2
the result is :
1 a
2 a
3 a
and not :
1 a
2 a
3 a
152 a
1896 a
Thanks for your help
Kevin
Tarek Hassan <[EMAIL PROTECTED]> writes:
> I am wondering what the reason behind
> this restriction is.
Because nobody has yet implemented joining on numeric fields. It's
been proposed, and it's a good suggestion. Basically, "join" should
be able to mimic "sort"'s comparisons. Can you help imp
Dear Sir/Madam:
The man page for the join command mentions that the input files must be sorted
on the join fields. I noticed that if numeric sorting is used, the output of
join misses some data. So join works properly only if lexicographic sorting is
used. Is this done by design? If so, I am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Samir Wadhawan on 1/31/2008 2:41 PM:
| Dear Mike Haertel,
Coreutils is maintained by more than just Mike (for that matter, it has
been years since Mike made any contributions, according to the ChangeLog).
| As indicated in the join's ma
Dear Mike Haertel,
We call to your attention what we find an unsual behaviour of join command
on ubuntu distributions (Dapper and above). Attached to this mail are the
two sample files (file1 and file2) which produces incorrect output when
joining column 5 of file1 with column 1 of file2. (There
Robert Castelo <[EMAIL PROTECTED]> writes:
> q.txt==(tab-separated columns)
> aa value-aa
> a value-a
> ===
> both versions 5.2.1 and 5.3.0 output
>
> aa value-aa
> a value-a
>
> when sorting over the entire line:
>
> sort q.txt
>
> or more specifically:
>
> sort
hi,
i think we're getting to the point.
> I assume we're talking about coreutils 5.2.1 here? I don't remember.
no, i was debugging on the source of coreutils-5.3.0.tar.gz but in my
fedora core-2 the "buggy" sort belongs to 5.2.1
in fact, the 5.3.0 version works right for the following case, co
Robert Castelo <[EMAIL PROTECTED]> writes:
> if i followed this right, xmemcoll is called at line 1536 of sort.c
> which calls memcoll at line 45 of xmemcoll.c which calls strcoll at line
> 47 of memcoll.c.
I assume we're talking about coreutils 5.2.1 here? I don't remember.
Two things. First,
Robert Castelo <[EMAIL PROTECTED]> writes:
>> ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz
>
> thanks, i've downloaded the sources but there is no call to strcoll
> within sort.c :-?
Please look for calls to xmemcoll, which eventually invokes strcoll.
> in any case, since my locale i
Robert Castelo <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] joinbug]$ uname -a
> Linux zapiron.imim.es 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686
> i686 i386 GNU/Linux
> [EMAIL PROTECTED] joinbug]$ locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> ...
> [EMAIL PROTECTED] joinbug]$ sort
Robert Castelo <[EMAIL PROTECTED]> writes:
> $ sort -k 1,1 q.txt
> aa value-aa
> a value-a
That looks bogus to me: "a" should sort before "aa", unless you have a
weird locale.
What's your platform? What do the following commands output on your
platform?
uname -a
locale
sort --versio
value-a
however, if i perform a join command on p.txt and q.txt it doesn't join
the line with the common value 'a' on the first column of both files!!
$ join p.txt q.txt
if i swap manually the lines in q.txt:
$ cat q.txt
a value-a
aa value-aa
and perform the join,
37 matches
Mail list logo
