Martin,
Martin Schmeing wrote:
Hi Bob,
Join works fine with my test smaller files, giving an appropriate
output. When both files are 1000 (short) lines long, it outputs
maybe one or two of the joined lines, but there should be hundreds
output. The files are sorted, and there is no error
Hello,
Is there a size limit for the input files for join? I want to do it with
large files, but even files of 1000 lines fail
Thanks,
Martin
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Hi,
I was trying to attach 2 files,
join -1 1 -2 1 Received_Packets Sent_Packets
The problem is, after the packet nr82, there is more numbers that
match, and the program just join the files until the packet nr82.
and file Received_Packets is:
4 25.109191
5 25.199239
6
Tiago Junqueira [EMAIL PROTECTED] writes:
Why i get after the command:
4 25.109191 25.00960
Your input is not sorted.
$ join --help
[...]
Important: FILE1 and FILE2 must be sorted on the join fields.
E.g., use `sort -k 1b,1' if `join' has no options.
Andreas.
--
Andreas Schwab, SuSE
hey, i think there is a bug in join command. i'm joining two sorted files
and there is no joining for an expected mapping. here is the example:
f1:
79 53
f2:
791 834
79 82
join f1 f2 == blank
if i change f2 to:
1791 834
79 82
join f1 f2 == 79 53 82
thanks,
erez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Erez PERELMAN on 9/19/2006 11:44 AM:
hey, i think there is a bug in join command. i'm joining two sorted
files and there is no joining for an expected mapping. here is the example:
f1:
79 53
f2:
791 834
79 82
Not a bug. join
On 2/6/06, Paul Eggert [EMAIL PROTECTED] wrote:
german rigau [EMAIL PROTECTED] writes:
Obviously, the problem is in the sort command. With C locale
runs perfectly. However, I use LANG=en_US.UTF-8 ...
And then it seems that the sort command have different behaviour ...
I don't see any
german rigau [EMAIL PROTECTED] writes:
If you see carefully the last example I sent, we obtain two different
sortings with locale en_US.UTF-8 ... with sort kk2 we obtain icecream
before ice_cream and with sort -k 1,2 kk2 we obtain ice_cream before
icecream!
That is because in that locale, _
german rigau [EMAIL PROTECTED] writes:
Obviously, the problem is in the sort command. With C locale
runs perfectly. However, I use LANG=en_US.UTF-8 ...
And then it seems that the sort command have different behaviour ...
I don't see any bug in the examples that you gave.
Getting back to the
Hello again,
Thanks a lot for you quick reply ...
But, BOTH files were sorted previously with default options.
[EMAIL PROTECTED] BaseConcepts]$ cat kk1
ice_cream%1:13:00::
life_style%1:07:00::
part-time%3:00:00::
[EMAIL PROTECTED] BaseConcepts]$ cat kk2
ice_cream%1:13:00:: 07510835 1 1
Hello again,
It seems to me that the problem is on the sort command ...
[EMAIL PROTECTED] BaseConcepts]$ sort kk2
icecream%1:13:00:: 07510835 1 0
ice_cream%1:13:00:: 07510835 1 1
life_style%1:07:00:: 04875322 1 2
part-time%3:00:00:: 01131371 1 21
[EMAIL PROTECTED] BaseConcepts]$ sort -k 1,2 kk2
On 2/3/06, Paul Eggert [EMAIL PROTECTED] wrote:
german rigau [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] BaseConcepts]$ more kk2.sort
icecream%1:13:00:: 07510835 1 0
ice_cream%1:13:00:: 07510835 1 1
life_style%1:07:00:: 04875322 1 2
part-time%3:00:00:: 01131371 1 21
kk2.sort isn't
Just in case this is really a bug...
I'm using version 5.2.1 of coreutils on a fedora core 4.
Consider joining these two files ordered with default options:
[EMAIL PROTECTED] BaseConcepts]$ more kk1.sort
ice_cream%1:13:00::
life_style%1:07:00::
part-time%3:00:00::
[EMAIL PROTECTED]
german rigau [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] BaseConcepts]$ more kk2.sort
icecream%1:13:00:: 07510835 1 0
ice_cream%1:13:00:: 07510835 1 1
life_style%1:07:00:: 04875322 1 2
part-time%3:00:00:: 01131371 1 21
kk2.sort isn't sorted correctly, at least not for the default C
locale.
14 matches
Mail list logo
