Re: Error on command Sort on linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to ozwin pais on 2/26/2009 4:42 PM: > Hi , > > We have RHEL 4( Linux 2.6.9-22.ELsmp) installed box. when we execute sort > -z 65536 filename its giving error please find below. > > # sort -z 65536 geo_panelist > /NOPRODUCTID > /silent > /infile geo_panelist 65536 > /keys 1 > /outfile - > \ > ^ > DMExpress : (PRLOR) record length value is out of range GNU sort does not output this message. Are you sure you are running the correct utility? 'which sort' and 'sort --version' should shed some light on the matter. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmnUsgACgkQ84KuGfSFAYAgAgCg1h6LEX10OYW50pqXsL14C4G7 hs0Ani933CneLGN+tY0JAAd4dH3r/9Nl =Wnjr -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -rl dir dir in 7.1 not so great
In my old 6.x something, cp would just say cp: cannot copy a directory, `dir', into itself, `dir/dir' (it would still do it, but only once) In 7.1 I get a result like this: % timeout 1 cp -rl dir dir % ls -R dir|wc -l 1063 Without the -l it still behaves properly. -- Mikael Magnusson removed directory: `dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir/dir' removed directory: `dir/dir/dir/dir' removed directory: `dir/dir/dir' removed directory: `dir/dir' removed directory: `dir' ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Error on command Sort on linux
Hi , We have RHEL 4( Linux 2.6.9-22.ELsmp) installed box. when we execute sort -z 65536 filename its giving error please find below. # sort -z 65536 geo_panelist /NOPRODUCTID /silent /infile geo_panelist 65536 /keys 1 /outfile - \ ^ DMExpress : (PRLOR) record length value is out of range Could you please help us to resolve this issue. Thanks and Regards Ozwin. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls (GNU coreutils) 6.12 bug: -d or --directory switch broken
On Thu, 26 Feb 2009, gero...@bluewin.ch wrote: I installed this version of coreutils to get proper accent support in french pathnames, but the ls command for managing directories silently fails. Could you give an example of the exact command you ran, what output was generated, and what output was expected? Without seeing a reproducible example of the bug it's hard to determine the cause of the problem. Please also see this FAQ, which might be relevant: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#ls-_002dd-does-not-list-directories_0021 Thanks, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH 1/2] maint: remove an unnecessary inclusion of
I spotted an unnecessary inclusion of signal.h, and then wrote the code to add signal.h to the list of headers "make syntax-check" tells you about when they're included without a use. Figuring out how to use $(subst with a space as an argument (aka how to set _sp to a space in a GNU makefile) was interesting. This would have done it, too, but seems more obtuse. _sp = _sp += >From 5be50ebb55ac284566dd0b15e26171edefe20929 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 24 Feb 2009 21:44:51 +0100 Subject: [PATCH 1/2] maint: remove an unnecessary inclusion of * src/operand2sig.c: Don't include . --- src/operand2sig.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/operand2sig.c b/src/operand2sig.c index 228db40..23f44bc 100644 --- a/src/operand2sig.c +++ b/src/operand2sig.c @@ -1,5 +1,5 @@ /* operand2sig.c -- common function for parsing signal specifications - Copyright (C) 2008 Free Software Foundation, Inc. + Copyright (C) 2008, 2009 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -24,7 +24,6 @@ #include #include #include -#include #if HAVE_SYS_WAIT_H # include -- 1.6.2.rc1.285.gc5f54 >From 731c71dfe7da23b753f68309f56800e3f413f98a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 24 Feb 2009 21:43:26 +0100 Subject: [PATCH 2/2] maint: detect unnecessary inclusion of signal.h * maint.mk (sc_prohibit_signal_without_use): New rule. --- maint.mk | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/maint.mk b/maint.mk index f1c1e8a..63b4c88 100644 --- a/maint.mk +++ b/maint.mk @@ -289,6 +289,43 @@ ctype_re = isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower\ sc_prohibit_c_ctype_without_use: @h='[<"]c-ctype.h[">]' re='\' \ msg='do not use HAVE''_FCNTL_H or O'_NDELAY \ -- 1.6.2.rc1.285.gc5f54 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls (GNU coreutils) 6.12 bug: -d or --directory switch broken
Hi, I installed this version of coreutils to get proper accent support in french pathnames, but the ls command for managing directories silently fails. I am kind of surprised no one noticed or that there is no regression test for such a bug, and that it was already noticed earlier. Am I alone on this one? My environment settings in the bash shell are: SHELL=/opt/local/bin/bash TERM=xterm-color OLDPWD=/usr/local LC_ALL=fr_CH.UTF-8 USER=root PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin PWD=/usr/local/bin LANG=fr_CH.UTF-8 LESSCHARSET=utf-8 SHLVL=1 HOME=/var/root LC_CTYPE=fr_CH.UTF-8 DISPLAY=:0 _=/opt/local/bin/printenv __CF_USER_TEXT_ENCODING=0x0:0:91 I installed with a classic: ./configure; make sudo make install It is located at /opt/local/bin/ls The shell is: powerbook-g4-15-de-schneider:/usr/local/bin root# bash --version GNU bash, version 3.2.48(1)-release (powerpc-apple-darwin8.11.0) Copyright (C) 2007 Free Software Foundation, Inc. Is there any kind of workaround or is there a newer version that fixed this? Thanks, Gerold Rupprecht Geneva, Switzerland ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] tests: stty-row-col would hang when run in the background
This makes the final stty test also ignore SIGTTOU. >From 3a914fa76dab3a4ee3dd2683866eeb664f505a00 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 26 Feb 2009 20:25:42 +0100 Subject: [PATCH] tests: stty-row-col would hang when run in the background * tests/misc/stty-row-col: Don't hang when run in background at least on Solaris 10 and OpenBSD. --- tests/misc/stty-row-col |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/tests/misc/stty-row-col b/tests/misc/stty-row-col index 987e0d5..c98ab15 100755 --- a/tests/misc/stty-row-col +++ b/tests/misc/stty-row-col @@ -1,7 +1,7 @@ #! /bin/sh # Test "stty" with rows and columns. -# Copyright (C) 1998-2001, 2003-2008 Free Software Foundation, Inc. +# Copyright (C) 1998-2001, 2003-2009 Free Software Foundation, Inc. # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -38,6 +38,7 @@ export LC_ALL . $srcdir/test-lib.sh require_controlling_input_terminal_ +trap '' TTOU # Ignore SIGTTOU # Versions of GNU stty from shellutils-1.9.2c and earlier failed # tests #2 and #4 when run on SunOS 4.1.3. -- 1.6.2.rc1.285.gc5f54 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort "b" option in pos2 has strange effect
For each fix, I usually try to determine when the bug was introduced and mention that in NEWS. Both of these date back to the very beginning, since sort from textutils-1.13 (yes, I actually built it ;-) exhibits the same incorrect behavior, and the code in that function barely changed between my initial import in 1992 and that 1.13. How many more +16-year-old bugs are lurking? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-7.1 requires trivial patch to build on IRIX/MIPSpro
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/26/2009 6:50 AM: >> >> Perhaps this approach would be better, Jim? > > Yes, indeed! > That looks much better. Thanks to both of you. > > ... >> - _ATTRIBUTE_NONNULL_ (1, 2); >> + _ATTRIBUTE_NONNULL_ (1) _ATTRIBUTE_NONNULL_ (2); Committed with this log entry: argv-iter: avoid variadic macro * gl/lib/argv-iter.h (_ATTRIBUTE_NONNULL_): Don't assume C99 variadic macros are portable yet; needed for at least IRIX/MIPSpro. * THANKS: Update. Reported by Stuart Shelton. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmmoLIACgkQ84KuGfSFAYBCAACgvrmWTDKTBw/EBWbycrZgvX65 kpcAnjjMhIoaFOcZkIoQEiX52fWEBZqY =j8Gi -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort "b" option in pos2 has strange effect
Pádraig Brady wrote:
...
>>> - /* If we're ignoring leading blanks when computing the End
>>> - of the field, don't start counting bytes until after skipping
>>> - past any leading blanks. */
>>> - if (key->skipeblanks)
>>> -while (ptr < lim && blanks[to_uchar (*ptr)])
>>> - ++ptr;
>>> + if (echar != 0) /* We need to skip over a portion of the end field. */
>>> +{
>>> + if (key->skipeblanks) /* blanks not counted in echar. */
>>
>> Was something wrong with the comment you're removing, above?
>
> I thought it was too verbose. It's replaced with:
> /* blanks not counted in echar. */
> which should be obvious in along with the code?
In that case, please stick with the longer comment.
Not only is it a complete sentence (which we prefer),
but I find it more readable/descriptive.
>>> + while (ptr < lim && blanks[to_uchar (*ptr)])
>>> + ++ptr;
>>>
>>> - /* Advance PTR by ECHAR (if possible), but no further than LIM. */
>>> - remaining_bytes = lim - ptr;
>>> - if (echar < remaining_bytes)
>>> -ptr += echar;
>>> - else
>>> -ptr = lim;
>>> + ptr = MIN (lim, ptr + echar);
>>> +}
>
> Same here. I removed the comment as the code is (now) obvious I think.
Removing that one is ok, I suppose.
But in general, please try to add rather than remove comments.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-7.1 requires trivial patch to build on IRIX/MIPSpro
Eric Blake wrote: > According to Stuart Shelton on 2/26/2009 5:37 AM: > > Hello Stuart, > >> >> The MIPSpro compiler is strict with variadic macros, requiring a macro >> defined as function(x,...) to be invoked with a minimum of two arguments >> (one for 'x', and at least one for the '...') >> >> coreutils-7.1 therefore requires this patch: >> >> --- lib/argv-iter.h.dist2009-02-25 17:06:43.143228800 + >> +++ lib/argv-iter.h 2009-02-25 17:06:50.654736800 + >> @@ -24,7 +24,7 @@ >> #if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || 3 < __GNUC__ >> # define _ATTRIBUTE_NONNULL_(m,...) __attribute__ ((__nonnull__ (m))) >> #else >> -# define _ATTRIBUTE_NONNULL_(m,...) >> +# define _ATTRIBUTE_NONNULL_(...) > > Thanks for the report. Actually, I'm surprised to see that variadic > macros are in use. Yes, coreutils already uses C99 decl-after-statement, > since most C89 compilers support that as an extension. But are variadic > macros really that portable? > > Perhaps this approach would be better, Jim? Yes, indeed! That looks much better. Thanks to both of you. ... > - _ATTRIBUTE_NONNULL_ (1, 2); > + _ATTRIBUTE_NONNULL_ (1) _ATTRIBUTE_NONNULL_ (2); ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-7.1 requires trivial patch to build on IRIX/MIPSpro
According to Stuart Shelton on 2/26/2009 5:37 AM: Hello Stuart, > > The MIPSpro compiler is strict with variadic macros, requiring a macro > defined as function(x,...) to be invoked with a minimum of two arguments > (one for 'x', and at least one for the '...') > > coreutils-7.1 therefore requires this patch: > > --- lib/argv-iter.h.dist2009-02-25 17:06:43.143228800 + > +++ lib/argv-iter.h 2009-02-25 17:06:50.654736800 + > @@ -24,7 +24,7 @@ > #if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || 3 < __GNUC__ > # define _ATTRIBUTE_NONNULL_(m,...) __attribute__ ((__nonnull__ (m))) > #else > -# define _ATTRIBUTE_NONNULL_(m,...) > +# define _ATTRIBUTE_NONNULL_(...) Thanks for the report. Actually, I'm surprised to see that variadic macros are in use. Yes, coreutils already uses C99 decl-after-statement, since most C89 compilers support that as an extension. But are variadic macros really that portable? Perhaps this approach would be better, Jim? diff --git a/gl/lib/argv-iter.h b/gl/lib/argv-iter.h index 06a397c..32b3eb3 100644 --- a/gl/lib/argv-iter.h +++ b/gl/lib/argv-iter.h @@ -1,5 +1,5 @@ /* Iterate over arguments from argv or --files0-from=FILE - Copyright (C) 2008 Free Software Foundation, Inc. + Copyright (C) 2008, 2009 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -22,9 +22,9 @@ enum argv_iter_err; #undef _ATTRIBUTE_NONNULL_ #if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || 3 < __GNUC__ -# define _ATTRIBUTE_NONNULL_(m,...) __attribute__ ((__nonnull__ (m))) +# define _ATTRIBUTE_NONNULL_(m) __attribute__ ((__nonnull__ (m))) #else -# define _ATTRIBUTE_NONNULL_(m,...) +# define _ATTRIBUTE_NONNULL_(m) #endif enum argv_iter_err @@ -40,7 +40,7 @@ struct argv_iterator *argv_iter_init_argv (char **argv) struct argv_iterator *argv_iter_init_stream (FILE *fp) _ATTRIBUTE_NONNULL_ (1); char *argv_iter (struct argv_iterator *, enum argv_iter_err *) - _ATTRIBUTE_NONNULL_ (1, 2); + _ATTRIBUTE_NONNULL_ (1) _ATTRIBUTE_NONNULL_ (2); size_t argv_iter_n_args (struct argv_iterator const *) _ATTRIBUTE_NONNULL_ (1); void argv_iter_free (struct argv_iterator *) -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort "b" option in pos2 has strange effect
Jim Meyering wrote:
> Pádraig Brady wrote:
>> I've tweaked the patch a bit to simplify some code
>> and expect to push it soon.
>>
>> Thanks to my friendly LUG I confirmed that solaris 9 and 10
>> behave as expected for these commands:
>>
>> printf "a a b\nz a a\n" | sort -k2,3.0
>> printf "a y\na z\n" | sort -k1,1b
>>
>> cheers,
>> Pádraig.
>> >From 4a1f5d98265cf74297d9e523aa99fca80cc51e3c Mon Sep 17 00:00:00 2001
>> From: =?utf-8?q?P=C3=A1draig=20Brady?=
>> Date: Tue, 24 Feb 2009 08:37:18 +
>> Subject: [PATCH] sort: Fix two bugs with determining the end of field
>>
>> * src/sort.c: When no specific number of chars to skip
>> is specified for the end field, always skip the whole field.
>> Also never include leading spaces from next field.
>> * tests/misc/sort: Add 2 new tests for these cases.
>> * NEWS: Mention this bug fix.
>> * THANKS: Add bug reporter.
>> Reported by Davide Canova
> ...
>
> Thanks! Looks fine.
> Only one question:
>
>> - /* If we're ignoring leading blanks when computing the End
>> - of the field, don't start counting bytes until after skipping
>> - past any leading blanks. */
>> - if (key->skipeblanks)
>> -while (ptr < lim && blanks[to_uchar (*ptr)])
>> - ++ptr;
>> + if (echar != 0) /* We need to skip over a portion of the end field. */
>> +{
>> + if (key->skipeblanks) /* blanks not counted in echar. */
>
> Was something wrong with the comment you're removing, above?
I thought it was too verbose. It's replaced with:
/* blanks not counted in echar. */
which should be obvious in along with the code?
>> +while (ptr < lim && blanks[to_uchar (*ptr)])
>> + ++ptr;
>>
>> - /* Advance PTR by ECHAR (if possible), but no further than LIM. */
>> - remaining_bytes = lim - ptr;
>> - if (echar < remaining_bytes)
>> -ptr += echar;
>> - else
>> -ptr = lim;
>> + ptr = MIN (lim, ptr + echar);
>> +}
Same here. I removed the comment as the code is (now) obvious I think.
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join command
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: "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 wrong ? Please try reducing your problem to the smallest possible pair of input files that reproduces the problem you're having. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-7.1 requires trivial patch to build on IRIX/MIPSpro
The MIPSpro compiler is strict with variadic macros, requiring a macro defined as function(x,...) to be invoked with a minimum of two arguments (one for 'x', and at least one for the '...') coreutils-7.1 therefore requires this patch: --- lib/argv-iter.h.dist2009-02-25 17:06:43.143228800 + +++ lib/argv-iter.h 2009-02-25 17:06:50.654736800 + @@ -24,7 +24,7 @@ #if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || 3 < __GNUC__ # define _ATTRIBUTE_NONNULL_(m,...) __attribute__ ((__nonnull__ (m))) #else -# define _ATTRIBUTE_NONNULL_(m,...) +# define _ATTRIBUTE_NONNULL_(...) #endif enum argv_iter_err ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join command
Eric Blake wrote: > 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 your attachments, > > Actually, I couldn't have validated them. Your mentioned .zip attachment > was not actually present; either you missed sending it, or the mail server > stripped it off. It is safe to send .gz, .bz2, or even .xz attachments, > 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 common field sorted with alphanumerical order and not numerical order (sort -n)." Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort "b" option in pos2 has strange effect
Pádraig Brady wrote:
> I've tweaked the patch a bit to simplify some code
> and expect to push it soon.
>
> Thanks to my friendly LUG I confirmed that solaris 9 and 10
> behave as expected for these commands:
>
> printf "a a b\nz a a\n" | sort -k2,3.0
> printf "a y\na z\n" | sort -k1,1b
>
> cheers,
> Pádraig.
>>From 4a1f5d98265cf74297d9e523aa99fca80cc51e3c Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?P=C3=A1draig=20Brady?=
> Date: Tue, 24 Feb 2009 08:37:18 +
> Subject: [PATCH] sort: Fix two bugs with determining the end of field
>
> * src/sort.c: When no specific number of chars to skip
> is specified for the end field, always skip the whole field.
> Also never include leading spaces from next field.
> * tests/misc/sort: Add 2 new tests for these cases.
> * NEWS: Mention this bug fix.
> * THANKS: Add bug reporter.
> Reported by Davide Canova
...
Thanks! Looks fine.
Only one question:
> - /* If we're ignoring leading blanks when computing the End
> - of the field, don't start counting bytes until after skipping
> - past any leading blanks. */
> - if (key->skipeblanks)
> -while (ptr < lim && blanks[to_uchar (*ptr)])
> - ++ptr;
> + if (echar != 0) /* We need to skip over a portion of the end field. */
> +{
> + if (key->skipeblanks) /* blanks not counted in echar. */
Was something wrong with the comment you're removing, above?
> + while (ptr < lim && blanks[to_uchar (*ptr)])
> + ++ptr;
>
> - /* Advance PTR by ECHAR (if possible), but no further than LIM. */
> - remaining_bytes = lim - ptr;
> - if (echar < remaining_bytes)
> -ptr += echar;
> - else
> -ptr = lim;
> + ptr = MIN (lim, ptr + echar);
> +}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join command
-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 your attachments, Actually, I couldn't have validated them. Your mentioned .zip attachment was not actually present; either you missed sending it, or the mail server stripped it off. It is safe to send .gz, .bz2, or even .xz attachments, but .zip tends to be used in propagating viruses, so I won't guarantee whether it can make it through unscathed. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmmleAACgkQ84KuGfSFAYCkowCghbHGjLBKjVnedz453P3gO+Pi OdQAn05vid3ENIulmOZ0gzoMT/STjTF0 =AEvJ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in join command
-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). > This command returns only 55 lines. > The real number in the output must be 1031 lines. > What's wrong ? It's likely that your files aren't properly sorted. While I didn't validate your attachments, 'join --help' is explicit that: Important: FILE1 and FILE2 must be sorted on the join fields. E.g., use `sort -k 1b,1' if `join' has no options. Additionally, if you upgrade to coreutils 7.1 (the latest stable version), join has an option to output a warning if it encounters unsorted input. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmmlT4ACgkQ84KuGfSFAYBJCACeIQGgbtuQb00Ki+Ejfg3dKE6a g+kAniqJwWa92HvkH26CvARltJ0hJWAp =3xIc -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort "b" option in pos2 has strange effect
I've tweaked the patch a bit to simplify some code
and expect to push it soon.
Thanks to my friendly LUG I confirmed that solaris 9 and 10
behave as expected for these commands:
printf "a a b\nz a a\n" | sort -k2,3.0
printf "a y\na z\n" | sort -k1,1b
cheers,
Pádraig.
>From 4a1f5d98265cf74297d9e523aa99fca80cc51e3c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?=
Date: Tue, 24 Feb 2009 08:37:18 +
Subject: [PATCH] sort: Fix two bugs with determining the end of field
* src/sort.c: When no specific number of chars to skip
is specified for the end field, always skip the whole field.
Also never include leading spaces from next field.
* tests/misc/sort: Add 2 new tests for these cases.
* NEWS: Mention this bug fix.
* THANKS: Add bug reporter.
Reported by Davide Canova
---
NEWS|6 ++
THANKS |1 +
src/sort.c | 38 +-
tests/misc/sort |6 ++
4 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/NEWS b/NEWS
index 82ded9d..05d22cb 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*- outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** Bug fixes
+
+ sort now handles specified key ends correctly.
+ Previously -k1,1b would have caused leading space from field 2 to be
+ included in the sort while -k2,3.0 would have not included field 3.
+
* Noteworthy changes in release 7.1 (2009-02-21) [stable]
diff --git a/THANKS b/THANKS
index 5c25321..4b35a37 100644
--- a/THANKS
+++ b/THANKS
@@ -137,6 +137,7 @@ David Godfrey d...@delta.demon.co.uk
David Luyer david_lu...@pacific.net.au
David Madoredavid.mad...@ens.fr
David Malonedwmal...@cnri.dit.ie
+Davide Canova kc.can...@gmail.com
Dawson Engler eng...@stanford.edu
Dean Gaudet dean-savan...@arctic.org
Deepak Goel de...@gnufans.org
diff --git a/src/sort.c b/src/sort.c
index f438563..27726a5 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1366,7 +1366,6 @@ begfield (const struct line *line, const struct keyfield *key)
char *ptr = line->text, *lim = ptr + line->length - 1;
size_t sword = key->sword;
size_t schar = key->schar;
- size_t remaining_bytes;
/* The leading field separator itself is included in a field when -t
is absent. */
@@ -1392,12 +1391,7 @@ begfield (const struct line *line, const struct keyfield *key)
while (ptr < lim && blanks[to_uchar (*ptr)])
++ptr;
- /* Advance PTR by SCHAR (if possible), but no further than LIM. */
- remaining_bytes = lim - ptr;
- if (schar < remaining_bytes)
-ptr += schar;
- else
-ptr = lim;
+ ptr = MIN (lim, ptr + schar);
return ptr;
}
@@ -1410,7 +1404,9 @@ limfield (const struct line *line, const struct keyfield *key)
{
char *ptr = line->text, *lim = ptr + line->length - 1;
size_t eword = key->eword, echar = key->echar;
- size_t remaining_bytes;
+
+ if (echar == 0)
+eword++; /* Skip all of end field. */
/* Move PTR past EWORD fields or to one past the last byte on LINE,
whichever comes first. If there are more than EWORD fields, leave
@@ -1487,19 +1483,14 @@ limfield (const struct line *line, const struct keyfield *key)
}
#endif
- /* If we're ignoring leading blanks when computing the End
- of the field, don't start counting bytes until after skipping
- past any leading blanks. */
- if (key->skipeblanks)
-while (ptr < lim && blanks[to_uchar (*ptr)])
- ++ptr;
+ if (echar != 0) /* We need to skip over a portion of the end field. */
+{
+ if (key->skipeblanks) /* blanks not counted in echar. */
+ while (ptr < lim && blanks[to_uchar (*ptr)])
+ ++ptr;
- /* Advance PTR by ECHAR (if possible), but no further than LIM. */
- remaining_bytes = lim - ptr;
- if (echar < remaining_bytes)
-ptr += echar;
- else
-ptr = lim;
+ ptr = MIN (lim, ptr + echar);
+}
return ptr;
}
@@ -3152,12 +3143,9 @@ main (int argc, char **argv)
badfieldspec (optarg, N_("field number is zero"));
}
if (*s == '.')
- s = parse_field_count (s + 1, &key->echar,
- N_("invalid number after `.'"));
- else
{
- /* `-k 2,3' is equivalent to `+1 -3'. */
- key->eword++;
+ s = parse_field_count (s + 1, &key->echar,
+ N_("invalid number after `.'"));
}
s = set_ordering (s, key, bl_end);
}
diff --git a/tests/misc/sort b/tests/misc/sort
index 3e8eda6..3af2388 100755
--- a/tests/misc/sort
+++ b/tests/misc/sort
@@ -110,6 +110,8 @@ my @Tests =
["07b", '-k 2,3', {IN=>"a a b\nz a a\n"}, {OUT=>"z a a\na a b\n"}],
["07c", '-k 2,3', {IN=>"y k b\nz k a\n"}, {OUT=>"z k a\ny k b\n"}],
["07d", '+1 -3', {IN=>"y k b\nz k a\n"}, {OUT=>"z k a\ny k b\n"}],
+# ensure a character position of 0 includes whole fiel
Re: bug in join command
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 lines. > The real number in the output must be 1031 lines. > What's wrong ? Please try reducing your problem to the smallest possible pair of input files that reproduces the problem you're having. Thanks, James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: two netbsd 1.6 test failures: skip-seek-past-file and install-C
Pádraig Brady wrote: >> FAIL: dd/skip-seek-past-file.log (exit: 1) >> -dd: `standard input': cannot skip: Value too large for defined data type >> +dd: `standard input': cannot skip: Value too large to be stored in data type > > This should be addressed by the attached patch. ... > Subject: [PATCH] tests: Remove system specific error strings > > * tests/dd/skip-seek-past-file: Just check for > the non system specific part of the error strings. > This was causing an erroneous failure on NetBSD 1.6 at least. Thanks. Confirmed: now that test passes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
