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
Martin Schmeing wrote:
> Is there a size limit for the input files for join?
Long lines will consume as much memory as needed to work with the full
size of the line. In the extreme if lines are extremely long then it
will use an extreme amount of memory. Size of memory is an effective
limit. Bu
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
"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, Su
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 25.28928
-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 bu
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
__
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 i
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
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 t
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
>
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
i
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
icecream
german rigau wrote:
> Just in case this is really a bug...
Thanks for reporting the problem. But I believe the problem is in
your use of the command.
> Consider joining these two files ordered with default options:
>
> [EMAIL PROTECTED] BaseConcepts]$ more kk1.sort
> ice_cream%1:13:00::
> life_
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
lo
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] BaseConcepts]
16 matches
Mail list logo
