[PATCH] better diagnostics for seq
Attached is a patch that enhances seq's diagnostics. If you agree
that this is the right way to go, I'll amend other files (ChangeLog,
etc.) as needed.
Steven Schubiger
diff --git a/src/seq.c b/src/seq.c
index 261a44b..4a6f96e 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -185,12 +185,38 @@ scan_arg (const char *arg)
static char const *
long_double_format (char const *fmt, struct layout *layout)
{
+ const char *fmt_scan;
size_t i;
+ size_t counted_directives = 0;
size_t prefix_len = 0;
size_t suffix_len = 0;
size_t length_modifier_offset;
bool has_L;
+ fmt_scan = (const char *) fmt;
+ while (*fmt_scan)
+{
+ if (*fmt_scan == ' ')
+fmt_scan++;
+ else
+{
+ if (*fmt_scan == '%'
+ && (*(fmt_scan + 1) != '%'
+ && *(fmt_scan + 1) != ' '
+ && *(fmt_scan + 1) != '\0'))
+{
+ counted_directives++;
+ fmt_scan += 2;
+}
+ else
+fmt_scan++;
+}
+}
+ if (counted_directives == 0)
+error (EXIT_FAILURE, 0, _("no %% directive"));
+ else if (counted_directives > 1)
+error (EXIT_FAILURE, 0, _("too many %% directives"));
+
for (i = 0; ! (fmt[i] == '%' && fmt[i + 1] != '%'); i += (fmt[i] == '%') + 1)
if (fmt[i])
prefix_len++;
@@ -209,8 +235,8 @@ long_double_format (char const *fmt, struct layout *layout)
length_modifier_offset = i;
has_L = (fmt[i] == 'L');
i += has_L;
- if (! strchr ("efgaEFGA", fmt[i]))
-return NULL;
+ if (! strchr ("efgaEFGA", fmt[i]))
+error (EXIT_FAILURE, 0, _("invalid directive: `%c%c'"), fmt[i - 1],
fmt[i]);
for (i++; ! (fmt[i] == '%' && fmt[i + 1] != '%'); i += (fmt[i] == '%') + 1)
if (fmt[i])
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Steven Schubiger wrote:
>> Attached is a patch that enhances seq's diagnostics. If you agree
>> that this is the right way to go, I'll amend other files (ChangeLog,
>> etc.) as needed.
>
> Seems sensible. This is what I get on a reasonably recent tree:
>
> $ ./seq -f% 1
> ./seq: memory exhausted
Oh! That's a bug in the latest code.
Actually that's due to a misinterpreted asprintf failure.
> Note however that on gutsy I get the expected:
>
> $ seq -f% 1
> seq: invalid format string: `%'
> Try `seq --help' for more information.
Here's one way to fix it:
diff --git a/src/seq.c b/src/seq.c
index 261a44b..b073fd1 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -1,5 +1,5 @@
/* seq - print sequence of numbers to standard output.
- Copyright (C) 1994-2007 Free Software Foundation, Inc.
+ Copyright (C) 1994-2008 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
@@ -209,7 +209,7 @@ long_double_format (char const *fmt, struct layout *layout)
length_modifier_offset = i;
has_L = (fmt[i] == 'L');
i += has_L;
- if (! strchr ("efgaEFGA", fmt[i]))
+ if (fmt[i] == '\0' || ! strchr ("efgaEFGA", fmt[i]))
return NULL;
for (i++; ! (fmt[i] == '%' && fmt[i + 1] != '%'); i += (fmt[i] == '%') + 1)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Pádraig Brady <[EMAIL PROTECTED]> wrote: > Seems sensible. This is what I get on a reasonably recent tree: > > $ ./seq -f% 1 > ./seq: memory exhausted > > Note however that on gutsy I get the expected: > > $ seq -f% 1 > seq: invalid format string: `%' > Try `seq --help' for more information. > > So perhaps you could use the existing patch/logic from gutsy? FWIW, with the patched version I get: $ ./src/seq -f% 1 ./src/seq: no % directive Should we be additionally calling usage (EXIT_FAILURE); where now error() with first argument as EXIT_FAILURE is being invoked? Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Steven Schubiger wrote: > Attached is a patch that enhances seq's diagnostics. If you agree > that this is the right way to go, I'll amend other files (ChangeLog, > etc.) as needed. Seems sensible. This is what I get on a reasonably recent tree: $ ./seq -f% 1 ./seq: memory exhausted Note however that on gutsy I get the expected: $ seq -f% 1 seq: invalid format string: `%' Try `seq --help' for more information. So perhaps you could use the existing patch/logic from gutsy? cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Steven Schubiger <[EMAIL PROTECTED]> wrote:
> Attached is a patch that enhances seq's diagnostics. If you agree
> that this is the right way to go, I'll amend other files (ChangeLog,
> etc.) as needed.
Thanks for working on that.
> diff --git a/src/seq.c b/src/seq.c
> index 261a44b..4a6f96e 100644
> --- a/src/seq.c
> +++ b/src/seq.c
> @@ -185,12 +185,38 @@ scan_arg (const char *arg)
> static char const *
> long_double_format (char const *fmt, struct layout *layout)
> {
> + const char *fmt_scan;
>size_t i;
> + size_t counted_directives = 0;
>size_t prefix_len = 0;
>size_t suffix_len = 0;
>size_t length_modifier_offset;
>bool has_L;
>
> + fmt_scan = (const char *) fmt;
> + while (*fmt_scan)
> +{
> + if (*fmt_scan == ' ')
> +fmt_scan++;
> + else
> +{
> + if (*fmt_scan == '%'
> + && (*(fmt_scan + 1) != '%'
> + && *(fmt_scan + 1) != ' '
> + && *(fmt_scan + 1) != '\0'))
> +{
> + counted_directives++;
> + fmt_scan += 2;
> +}
> + else
> +fmt_scan++;
> +}
> +}
> + if (counted_directives == 0)
> +error (EXIT_FAILURE, 0, _("no %% directive"));
This might be a little more readable:
error (EXIT_FAILURE, 0, _("no %% directive in format %s"), quote (fmt));
> + else if (counted_directives > 1)
> +error (EXIT_FAILURE, 0, _("too many %% directives"));
> +
I think you can simplify that.
How about something like this?
unsigned int n_directives = 0;
char const *p = fmt;
for (p = fmt; *p; p++)
{
if (*p == '%')
{
if (p[1] != '%' && p[1] != '\0')
{
++n_directives;
++p;
}
}
}
Of course, it'd be nice to have a comment or two.
Even better: just add a new function to validate the format string,
including your two new diagnostics. Then the standard function-
describing comment will suffice.
> - if (! strchr ("efgaEFGA", fmt[i]))
> -return NULL;
> + if (! strchr ("efgaEFGA", fmt[i]))
> +error (EXIT_FAILURE, 0, _("invalid directive: `%c%c'"), fmt[i - 1],
> fmt[i]);
It's probably not worth a new test here,
since this is already handled by the caller.
The full directive may be many bytes long, so in general, %c%c is not
enough. Also, please don't add literal `' quotes in diagnostics.
If you want to quote something, use one of the quote* functions.
Please add test cases that exercise the new code
and test for the expected (new) diagnostics.
Each new test case should be in the form of a new line or two
in the file, tests/misc/seq.
When testing for a diagnostic, use this one as a model:
['fmt-c',qw(-f %%g 1), {EXIT => 1},
{ERR => "seq: invalid format string: `%%g'\n"
. "Try `seq --help' for more information.\n"},
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Steven Schubiger <[EMAIL PROTECTED]> wrote: ... > Should we be additionally calling usage (EXIT_FAILURE); where now > error() with first argument as EXIT_FAILURE is being invoked? On one hand, I'm tempted to say if the user uses -f with a format string containing no % directive at all, then maybe they need to look at --help output, so maybe calling "usage" would be good. On the other hand, I have personally wanted to use seq with a format string containing *no* % directive (hence the TODO item to consider allowing that). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Steven Schubiger wrote:
>> Attached is a patch that enhances seq's diagnostics. If you agree
>> that this is the right way to go, I'll amend other files (ChangeLog,
>> etc.) as needed.
>
> Seems sensible. This is what I get on a reasonably recent tree:
>
> $ ./seq -f% 1
> ./seq: memory exhausted
Thanks again.
Here's the patch I've just pushed:
seq: give a proper diagnostic for an invalid --format=% option
* src/seq.c (long_double_format): Handle '%' at end of string.
* tests/misc/seq [fmt-eos1, fmt-eos2]: New tests for the bug.
* NEWS: Mention this.
Reported by Pádraig Brady.
Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
NEWS |4
src/seq.c |4 ++--
tests/misc/seq | 16
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/NEWS b/NEWS
index 34fda4e..bc1b47d 100644
--- a/NEWS
+++ b/NEWS
@@ -12,6 +12,10 @@ GNU coreutils NEWS-*-
outline -*-
"rmdir --ignore-fail-on-non-empty" detects and ignores the failure
in more cases when a directory is empty.
+ "seq -f % 1" would issue the erroneous diagnostic "seq: memory exhausted"
+ rather than reporting the invalid string format.
+ [bug introduced in coreutils-6.0]
+
** Improvements
ls --color no longer outputs unnecessary escape sequences
diff --git a/src/seq.c b/src/seq.c
index 261a44b..b073fd1 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -1,5 +1,5 @@
/* seq - print sequence of numbers to standard output.
- Copyright (C) 1994-2007 Free Software Foundation, Inc.
+ Copyright (C) 1994-2008 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
@@ -209,7 +209,7 @@ long_double_format (char const *fmt, struct layout *layout)
length_modifier_offset = i;
has_L = (fmt[i] == 'L');
i += has_L;
- if (! strchr ("efgaEFGA", fmt[i]))
+ if (fmt[i] == '\0' || ! strchr ("efgaEFGA", fmt[i]))
return NULL;
for (i++; ! (fmt[i] == '%' && fmt[i + 1] != '%'); i += (fmt[i] == '%') + 1)
diff --git a/tests/misc/seq b/tests/misc/seq
index 9c1e48f..1a153a3 100755
--- a/tests/misc/seq
+++ b/tests/misc/seq
@@ -2,7 +2,7 @@
# -*- perl -*-
# Test "seq".
-# Copyright (C) 1999, 2000, 2003, 2005-2007 Free Software Foundation, Inc.
+# Copyright (C) 1999, 2000, 2003, 2005-2008 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
@@ -31,6 +31,7 @@ use strict;
@ENV{qw(LANGUAGE LANG LC_ALL)} = ('C') x 3;
my $prog = 'seq';
+my $try_help = "Try `$prog --help' for more information.\n";
my @Tests =
(
@@ -80,9 +81,16 @@ my @Tests =
# In coreutils-[6.0..6.9], this would mistakenly succeed and print "%Lg".
['fmt-c', qw(-f %%g 1), {EXIT => 1},
-{ERR => "seq: invalid format string: `%%g'\n"
- . "Try `seq --help' for more information.\n"},
-],
+{ERR => "seq: invalid format string: `%%g'\n" . $try_help }],
+
+ # In coreutils-6.9..6.10, this would fail with an erroneous diagnostic:
+ # "seq: memory exhausted". In coreutils-6.0..6.8, it would mistakenly
+ # succeed and print a blank line.
+ ['fmt-eos1', qw(-f % 1), {EXIT => 1},
+{ERR => "seq: invalid format string: `%'\n" . $try_help }],
+ ['fmt-eos2', qw(-f %g% 1), {EXIT => 1},
+{ERR => "seq: invalid format string: `%g%'\n" . $try_help }],
+
);
# Append a newline to each entry in the OUT array.
--
1.5.4.2.124.gc4db3
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
new sort option (or one I don't know about that already exists...:-) )
Am I the only one who likes to do things like ls -lh1 or du -sh * and would like to be able to sort the output sizes "correctly"? I know I can du -s *|sort -n, but then it isn't "human readable". If I'm the only one...well...Foo!...:-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new sort option (or one I don't know about that already exists...:-) )
Linda Walsh <[EMAIL PROTECTED]> wrote: > Am I the only one who likes to do things like > ls -lh1 >or > du -sh * > > and would like to be able to sort the output sizes "correctly"? > > I know I can du -s *|sort -n, but then it isn't "human readable". Right :-) This has been proposed before, and would be a welcome addition. We're just waiting for someone to prepare a proper patch, (documentation, NEWS, tests, ChangeLog entries, copyright assignment) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
What does it do? You said it reset somebody's boss's access so he could not read some file. Was this hyperbole? When I just tried it on a local directory, "chown -R ." gave an error, while "chown -R : ." appeared to do nothing on linux, under cygwin, it did reset 'group' id's from "null" (uid=-1) to my default group, but didn't affect other groups. But I haven't found a linux case where it does something, yet... :-) [EMAIL PROTECTED] wrote: P> Is this just an academic worry, or were you really bitten by it? Yes. About once a year I do chown -R . file, thinking that -R meant recursive, oops, I mean "reference"... never expecting it to "work if it doesn't work", as with most commands, if it doesn't complain, then it must have worked, and one doesn't look back, until a month later when one notices some files didn't get written and were now lost due to a permission problem. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
LW> "chown -R ." gave an error Try DJ> chown -R . file which should emit "Holmes, you think you are changing the owner of FILE to be the same as the owner of ".", but you have actually typed something else (-R means recursive) which is an absolute error, about which the new improved chown command will hereby exit 1". ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 2/18/2008 11:56 AM: | LW> "chown -R ." gave an error | Try | DJ> chown -R . file | which should emit | "Holmes, you think you are changing the owner of FILE to be the same | as the owner of ".", but you have actually typed something else (-R | means recursive) which is an absolute error, about which the new | improved chown command will hereby exit 1". But why should it be an absolute error? We have already pointed out to you that resetting to defaults is not necessarily a no-op, therefore, who's to say that we can gratuitously break someone else's usage where they depended on this command to actually do something? You have to give more arguments why your usage pattern should warrant a warning, because I see no inherent reason why using the tool to reset the default group is wrong. And meanwhile, you should get used to using long options, since they aren't as ambiguous (not to mention that in general across the coreutils, tools that supply -R generally mean recursive). In general, the coreutils should NOT make assumptions that you meant --reference when you typed -R - you get what you typed. But ultimately, since this problem doesn't seem to bother anyone else, you'll get more results if you provide a patch than if you just complain. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHueWg84KuGfSFAYARAvAxAJ9Iwpq3l09vXrUWEuk58g3WWdXQ8QCgijaB O1oty3550Hah+ySglQ59NyY= =y2Ak -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 2/18/2008 11:34 AM: Please don't top-post - on this list, we prefer to see replies in context. | What does it do? You said it reset somebody's boss's access so he could | not read some file. Was this hyperbole? When I just tried it on a | local directory, "chown -R ." gave an error, while "chown -R : ." | appeared to do nothing on linux, under cygwin, it did reset 'group' id's | from "null" (uid=-1) to my default group, but didn't affect other groups. | But I haven't found a linux case where it does something, yet... :-) Hmm. The info documentation states: OWNER`:' ~ If a colon but no group name follows OWNER, that user is made the ~ owner of the files and the group of the files is changed to ~ OWNER's login group. `:' ~ If only a colon is given, or if NEW-OWNER is empty, neither the ~ owner nor the group is changed. But you claim that using just `:' (or it's obsolete synonym `.') resulted in changing the group to the default login group, rather than being a no-op. I'm wondering whether this is a cygwin porting bug or an upstream documentation bug. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHueYi84KuGfSFAYARAiilAJ4indLMVFhkTp5vt2AxMST7Og4bSQCgo2vk Tsq0+JOBQh25LceJbNAmC2Y= =b+hw -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
[EMAIL PROTECTED] wrote: > LW> "chown -R ." gave an error > Try > DJ> chown -R . file > which should emit > "Holmes, you think you are changing the owner of FILE to be the same > as the owner of ".", but you have actually typed something else (-R > means recursive) which is an absolute error, about which the new > improved chown command will hereby exit 1". I think it makes sense to diagnose a spec of "." as invalid. If you want the no-op spec, you can use ":", and as Dan points out, otherwise it's too easy for chown to interpret an intended FILE argument of "." as a spec. Any scripts that rely on "chown . FILE" succeeding should have been changed long ago. Does anyone want to work on this? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new sort option (or one I don't know about that already exists...:-) )
Jim Meyering wrote: This has been proposed before, and would be a welcome addition. We're just waiting for someone to prepare a proper patch, (documentation, NEWS, tests, ChangeLog entries, copyright assignment) Oh the benefits of Open Source! *forced-grin*... Hey, some of us come up with more ideas than we can begin to implement... *sigh*... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
EB> `:' EB> ~ If only a colon is given, or if NEW-OWNER is empty, neither the EB> ~ owner nor the group is changed. OK, I'll drop my case, but please add a comment to this documentation about "why" or "who knows why?" or the motivation behind or uses of, this case. Perhaps "just to be orthogonal". Else people wonder what's up the sleeve. JM> I think it makes sense to diagnose a spec of "." as invalid. OK, you dudes take it from here. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Thanks for working on that.
Attached is a revised patch that should take "appropriately" care of
your suggestions. I ran make check and all tests passed. Furthermore,
I checked coreutils.texi, but there seems to be no relevant documentation
for seq with regard to diagnostics (as expected). FYI, make distcheck
ungracefully exits with "fuzzy patch".
Steven Schubiger
diff --git a/ChangeLog-2008 b/ChangeLog-2008
index aac9feb..df88058 100644
--- a/ChangeLog-2008
+++ b/ChangeLog-2008
@@ -1,3 +1,13 @@
+2008-02-18 Steven Schubiger <[EMAIL PROTECTED]>
+
+ seq: give better diagnostics for invalid formats.
+ * src/seq.c: (validate_format): New function.
+ (main): Use it.
+ * tests/misc/seq: Test for expected diagnostics with
+ invalid formats.
+ * NEWS: Mention this change.
+ * TODO: Remove this item.
+
2008-02-07 Jim Meyering <[EMAIL PROTECTED]>
We *do* need two different version files.
diff --git a/NEWS b/NEWS
index 34fda4e..6cd73d4 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,8 @@ GNU coreutils NEWS-*-
outline -*-
ls --color no longer outputs unnecessary escape sequences
+ seq gives better diagnostics for invalid formats.
+
** Consistency
mkdir and split now write --verbose output to stdout, not stderr.
diff --git a/TODO b/TODO
index 8c6b6fc..3f4d26c 100644
--- a/TODO
+++ b/TODO
@@ -61,8 +61,6 @@ printf: consider adapting builtins/printf.def from bash
df: add `--total' option, suggested here http://bugs.debian.org/186007
-seq: give better diagnostics for invalid formats:
- e.g. no or too many % directives
seq: consider allowing format string to contain no %-directives
tail: don't use xlseek; it *exits*.
diff --git a/src/seq.c b/src/seq.c
index 261a44b..08fb664 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -1,5 +1,5 @@
/* seq - print sequence of numbers to standard output.
- Copyright (C) 1994-2007 Free Software Foundation, Inc.
+ Copyright (C) 1994-2008 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
@@ -177,6 +177,35 @@ scan_arg (const char *arg)
return ret;
}
+/* Validate the FORMAT format. Print a diagnostic and exit
+ when no directives or too many were found. */
+
+static void
+validate_format (char const *fmt)
+{
+ unsigned int n_directives = 0;
+ char const *p;
+
+ for (p = fmt; *p; p++)
+{
+ if (*p == '%')
+{
+ if (p[1] != '%' && p[1] != '\0')
+{
+ ++n_directives;
+ ++p;
+}
+}
+}
+ if (! n_directives)
+{
+ error (0, 0, _("no %% directive in format %s"), quote (fmt));
+ usage (EXIT_FAILURE);
+}
+ else if (n_directives > 1)
+error (EXIT_FAILURE, 0, _("too many %% directives in format %s"), quote
(fmt));
+}
+
/* If FORMAT is a valid printf format for a double argument, return
its long double equivalent, possibly allocated from dynamic
storage, and store into *LAYOUT a description of the output layout;
@@ -405,7 +434,11 @@ main (int argc, char **argv)
if (format_str)
{
- char const *f = long_double_format (format_str, &layout);
+ char const *f;
+
+ validate_format (format_str);
+
+ f = long_double_format (format_str, &layout);
if (! f)
{
error (0, 0, _("invalid format string: %s"), quote (format_str));
diff --git a/tests/misc/seq b/tests/misc/seq
index 9c1e48f..4e2d128 100755
--- a/tests/misc/seq
+++ b/tests/misc/seq
@@ -2,7 +2,7 @@
# -*- perl -*-
# Test "seq".
-# Copyright (C) 1999, 2000, 2003, 2005-2007 Free Software Foundation, Inc.
+# Copyright (C) 1999, 2000, 2003, 2005-2008 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
@@ -82,6 +82,13 @@ my @Tests =
['fmt-c', qw(-f %%g 1), {EXIT => 1},
{ERR => "seq: invalid format string: `%%g'\n"
. "Try `seq --help' for more information.\n"},
+ ],
+ ['fmt-d', qw(-f "" 1), {EXIT => 1},
+{ERR => "seq: no % directive in format `'\n"
+ . "Try `seq --help' for more information.\n"},
+ ],
+ ['fmt-e', qw(-f %g%g 1), {EXIT => 1},
+{ERR => "seq: too many % directives in format `%g%g'\n"},
],
);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown should catch null owner:group
Eric Blake wrote: But why should it be an absolute error? We have already pointed out to you that resetting to defaults is not necessarily a no-op, I haven't tested every case, but this isn't what it did on my machine. It didn't reset the g+s bit on a dir, and the only time it changed a group was when the group was effectively "-1". It didn't change it to my "default" group. However, it may easily be the case that all of the groups in the directory I checked were in my supplementary groups -- but I know it just activate off of the default group. Not saying what it "should" do...just what it is currently doing (and only on cygwin that I could tell; linux's seemed to behave as as a no-op (or I didn't catch what it did...:-/)). I'm not real sure what the default behavior is "supposed to be doing", let alone what it should be doing...:-). -l ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new sort option (or one I don't know about that already exists...:-) )
On Feb 18, 2008 6:41 PM, Linda Walsh <[EMAIL PROTECTED]> wrote: > Am I the only one who likes to do things like [...] > du -sh * I hope so; in the general case (i.e. with other tools) it can have unpredictable effects. Using ./* instead of * is safer. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Check the order of the input by default, if there are unpairable input lines.
This patch amends my previous changes to join.c to enable
order-checking by default for the case where the user is not making
use of the extension of processing unsorted inputs containing only
pairable lines. This idea was suggestied by Pádraig Brady.
2008-02-18 James Youngman <[EMAIL PROTECTED]>
Enable order-checking of join's input where the user is not
making use of the GNU extension for processing unsorted input
files containing only pairable input lines (idea from Pádraig
Brady).
* src/join.c: New variables seen_unpairable and
issued_disorder_warning[]. Changed type of check_input_order from
a boolean to a tristate (enabled/disabled/default).
(get_line): Also check input order in the default case (i.e. when
neither --check-order not --nocheck-order is specified). In the
default case, we issue a warning only when there are unpairable
input lines and one of the inputs is out of order.
(checkorder): Obey the tristate variable check_input_order.
Avoid unnecessary comparisons.
(join): Also perform ordering checks after reaching EOF on one
input.
* coreutils.texi (join invocation): Explain the handling of the
default case where neither --check-order nor --nocheck-order is
specified.
Signed-off-by: James Youngman <[EMAIL PROTECTED]>
---
doc/coreutils.texi | 30 +--
src/join.c | 100 ++-
2 files changed, 100 insertions(+), 30 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b110273..e8ccb4b 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,17 +5149,10 @@ sort a file on its default join field, but if you
select a non-default
locale, join field, separator, or comparison options, then you should
do so consistently between @command{join} and @command{sort}.
[EMAIL PROTECTED] Unsorted inputs are a common cause of FAQs, but we probably
[EMAIL PROTECTED] should not make --check-order the default, as we documented
this
[EMAIL PROTECTED] extension and so should continue to allow it
-.
-If the @option{--check-order} option is given, unsorted inputs will
-cause a fatal error message. If the @option{--check-order} option is
-not given, a @acronym{GNU} extension is available: if the input has no
-unpairable lines the sort order can be any order that considers two
-fields to be equal if and only if the sort comparison described above
-considers them to be equal.
-For example:
+If the input has no unpairable lines, a @acronym{GNU} extension is
+available; the sort order can be any order that considers two fields
+to be equal if and only if the sort comparison described above
+considers them to be equal. For example:
@example
$ cat file1
@@ -5176,6 +5169,19 @@ c c1 c2
b b1 b2
@end example
+If the @option{--check-order} option is given, unsorted inputs will
+cause a fatal error message. If the option @option{--nocheck-order}
+is given, unsorted inputs will never cause an error message. If
+neither of these options is given, wrongly sorted inputs are diagnosed
+only if an input file is found to contain unpairable lines. If an
+input file is diagnosed as being unsorted, the @command{join} command
+will exit with a nonzero status (and the output should not be used).
+
+Forcing @command{join} to process wrongly sorted input files
+containing unpairable lines by specifying @option{--nocheck-order} is
+not guaranteed to produce any particular output. The output will
+probably not correspond with whatever you hoped it would be.
+
The defaults are:
@itemize
@item the join field is the first field in each line;
@@ -5196,7 +5202,7 @@ Print a line for each unpairable line in file
@var{file-number} (either
@samp{1} or @samp{2}), in addition to the normal output.
@item --check-order
-Check that both input files are in sorted order.
+Fail with an error message if either input file is wrongly ordered.
@item --nocheck-order
Do not check that both input files are in sorted order. This is the default.
diff --git a/src/join.c b/src/join.c
index 67f81b5..925835e 100644
--- a/src/join.c
+++ b/src/join.c
@@ -90,6 +90,12 @@ static bool print_unpairables_1, print_unpairables_2;
/* If nonzero, print pairable lines. */
static bool print_pairables;
+/* If nonzero, we have seen at least one unpairable line. */
+static bool seen_unpairable;
+
+/* If nonzero, we have warned about disorder in that file. */
+static bool issued_disorder_warning[2];
+
/* Empty output field filler. */
static char const *empty_filler;
@@ -109,7 +115,13 @@ static struct outlist *outlist_end = &outlist_head;
static int tab = -1;
/* If nonzero, check that the input is correctly ordered. */
-static bool check_input_order = false;
+enum
+ {
+ CHECK_ORDER_DEFAULT,
+ CHECK_ORDER_ENABLED,
+ CHECK_ORDER_DISABLED
+ } check_input_order;
+
enum
{
@@ -304,15 +316,12 @@
Re: sort --compare-version
Jim Meyering <[EMAIL PROTECTED]> writes:
> Do you feel like adding a few tests (tests/sort/Test.pm) to exercise
> the new feature, and adding to coreutils.texi and NEWS?
Here is an updated patch.
Andreas.
2008-02-18 Andreas Schwab <[EMAIL PROTECTED]>
Add --sort option.
* src/sort.c (SORT_OPTION): New enum.
(sort_args, sort_types): Define.
(usage, long_options, main): New option --sort.
* tests/sort/Test.pm: Test it.
doc/:
* coreutils.texi (sort invocation): Document --sort option.
diff --git a/NEWS b/NEWS
index bc1b47d..fb46361 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,13 @@ GNU coreutils NEWS-*-
outline -*-
* Noteworthy changes in release 6.?? (2008-??-??) [stable]
+** New features
+
+ sort accepts the new option --sort=WORD, where WORD can be one of
+ general-numeric, month, numeric or random. These are equivalent to the
+ options --general-numeric-sort/-g, --month-sort/-M, --numeric-sort/-n
+ and --random-sort/-R, resp.
+
** Bug fixes
configure --enable-no-install-program=groups now works.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 016673a..7d9cbcb 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3536,8 +3536,10 @@ The @env{LC_CTYPE} locale determines character types.
@item -g
@itemx --general-numeric-sort
[EMAIL PROTECTED] --sort=general-numeric
@opindex -g
@opindex --general-numeric-sort
[EMAIL PROTECTED] --sort
@cindex general numeric sort
@vindex LC_NUMERIC
Sort numerically, using the standard C function @code{strtod} to convert
@@ -3580,8 +3582,10 @@ This option has no effect if the stronger
@option{--dictionary-order}
@item -M
@itemx --month-sort
[EMAIL PROTECTED] --sort=month
@opindex -M
@opindex --month-sort
[EMAIL PROTECTED] --sort
@cindex months, sorting by
@vindex LC_TIME
An initial string, consisting of any amount of blanks, followed
@@ -3594,8 +3598,10 @@ can change this.
@item -n
@itemx --numeric-sort
[EMAIL PROTECTED] --sort=numeric
@opindex -n
@opindex --numeric-sort
[EMAIL PROTECTED] --sort
@cindex numeric sort
@vindex LC_NUMERIC
Sort numerically. The number begins each line and consists
@@ -3623,8 +3629,10 @@ appear earlier in the output instead of later.
@item -R
@itemx --random-sort
[EMAIL PROTECTED] --sort=random
@opindex -R
@opindex --random-sort
[EMAIL PROTECTED] --sort
@cindex random sort
Sort by hashing the input keys and then sorting the hash values.
Choose the hash function at random, ensuring that it is free of
diff --git a/src/sort.c b/src/sort.c
index 1183fc5..79cca18 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -329,6 +329,9 @@ Ordering options:\n\
-n, --numeric-sort compare according to string numerical value\n\
-R, --random-sort sort by random hash of keys\n\
--random-source=FILEget random bytes from FILE (default
/dev/urandom)\n\
+ --sort=WORD sort according to WORD:\n\
+ general-numeric -g, month -M, numeric -n,\n\
+random -R\n\
-r, --reverse reverse the result of comparisons\n\
\n\
"), stdout);
@@ -391,7 +394,8 @@ enum
{
CHECK_OPTION = CHAR_MAX + 1,
COMPRESS_PROGRAM_OPTION,
- RANDOM_SOURCE_OPTION
+ RANDOM_SOURCE_OPTION,
+ SORT_OPTION
};
static char const short_options[] = "-bcCdfgik:mMno:rRsS:t:T:uy:z";
@@ -411,6 +415,7 @@ static struct option const long_options[] =
{"numeric-sort", no_argument, NULL, 'n'},
{"random-sort", no_argument, NULL, 'R'},
{"random-source", required_argument, NULL, RANDOM_SOURCE_OPTION},
+ {"sort", required_argument, NULL, SORT_OPTION},
{"output", required_argument, NULL, 'o'},
{"reverse", no_argument, NULL, 'r'},
{"stable", no_argument, NULL, 's'},
@@ -434,6 +439,16 @@ static char const check_types[] =
};
ARGMATCH_VERIFY (check_args, check_types);
+static char const *const sort_args[] =
+{
+ "general-numeric", "month", "numeric", "random", NULL
+};
+static char const sort_types[] =
+{
+ 'g', 'M', 'n', 'R'
+};
+ARGMATCH_VERIFY (sort_args, sort_types);
+
/* The set of signals that are caught. */
static sigset_t caught_signals;
@@ -2902,6 +2917,9 @@ main (int argc, char **argv)
files[nfiles++] = optarg;
break;
+ case SORT_OPTION:
+ c = XARGMATCH ("--sort", optarg, sort_args, sort_types);
+ /* Fall through. */
case 'b':
case 'd':
case 'f':
diff --git a/tests/sort/Test.pm b/tests/sort/Test.pm
index e4d98be..0462973 100644
--- a/tests/sort/Test.pm
+++ b/tests/sort/Test.pm
@@ -274,6 +274,7 @@ my @tv = (
["incompat4", '-c -o /dev/null', '', '', 2],
["incompat5", '-C -o /dev/null', '', '', 2],
["incompat6", '-cC', '', '', 2],
+["incompat7", '--sort=random -n', '', '', 2],
# -t '\0' is accepted, as of coreutils-5.0.91
['nul-tab', "-k2,2 -t '\\0'", "a\0z\01\nb\0y\02\n", "b\0y\02\na\0z\01\n", 0],
@@ -289,6 +290,9 @@ my @tv = (
# Exe
Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.
James Youngman <[EMAIL PROTECTED]> wrote: > This patch amends my previous changes to join.c to enable > order-checking by default for the case where the user is not making > use of the extension of processing unsorted inputs containing only > pairable lines. This idea was suggestied by Pádraig Brady. > > 2008-02-18 James Youngman <[EMAIL PROTECTED]> > > Enable order-checking of join's input where the user is not > making use of the GNU extension for processing unsorted input > files containing only pairable input lines (idea from Pádraig > Brady). ... Thanks for pursuing this. Same tests as before? IMHO, it's good to keep them in the same change set. There are a few trailing blanks, too. Repeat after me: "make distcheck", "make distcheck", ... :) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.
On Feb 18, 2008 11:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Thanks for pursuing this. > Same tests as before? Yes, one had to be removed (it verified that no oder checking was done by default). > IMHO, it's good to keep them in the same change set. > > There are a few trailing blanks, too. > Repeat after me: "make distcheck", "make distcheck", ... :) I can send the changes all again in a single patch (is that what you meant by "change set"?) and fix the trailing blanks too if you like. James ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] better diagnostics for seq
Steven Schubiger <[EMAIL PROTECTED]> wrote:
> Attached is a revised patch that should take "appropriately" care of
> your suggestions. I ran make check and all tests passed. Furthermore,
> I checked coreutils.texi, but there seems to be no relevant documentation
> for seq with regard to diagnostics (as expected). FYI, make distcheck
> ungracefully exits with "fuzzy patch".
>
> Steven Schubiger
>
> diff --git a/ChangeLog-2008 b/ChangeLog-2008
> index aac9feb..df88058 100644
> --- a/ChangeLog-2008
> +++ b/ChangeLog-2008
> @@ -1,3 +1,13 @@
> +2008-02-18 Steven Schubiger <[EMAIL PROTECTED]>
> +
> + seq: give better diagnostics for invalid formats.
> + * src/seq.c: (validate_format): New function.
> + (main): Use it.
> + * tests/misc/seq: Test for expected diagnostics with
> + invalid formats.
> + * NEWS: Mention this change.
> + * TODO: Remove this item.
Thanks.
BTW, I still do require ChangeLog entries, but not in any file.
Now, they end up in the git commit log, and eventually in a generated
ChangeLog that is created in the release tarball at "make dist" time.
The "fuzzy patch" error means the c99-to-c89.diff file needs
to be updated. Currently, that has to be resolved manually
by running "make patch-check REGEN_PATCH=yes" and then copying
new-diff to src/c99-to-c89.diff. I've just done that.
I made a few changes to your patch, and added a new change set
to update src/c99-to-c89.diff, below. I'll push this tomorrow.
---
>From f0e9eb150c4f97211de4ebd609091e2cef88898e Mon Sep 17 00:00:00 2001
From: Steven Schubiger <[EMAIL PROTECTED]>
Date: Mon, 18 Feb 2008 22:39:22 +0100
Subject: [PATCH] seq: give better diagnostics for invalid formats.
* src/seq.c: (validate_format): New function.
(main): Use it.
* tests/misc/seq (fmt-d, fmt-e): Test for expected diagnostics with
invalid formats.
* NEWS: Mention this change.
* TODO: Remove this item.
[jm: src/seq.c: make diagnostics more consistent
tests/misc/seq (fmt-eos1): adjust the expected diagnostic ]
Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
NEWS |2 ++
TODO |2 --
src/seq.c | 28
tests/misc/seq |6 +-
4 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/NEWS b/NEWS
index bc1b47d..d5d6737 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,8 @@ GNU coreutils NEWS-*-
outline -*-
ls --color no longer outputs unnecessary escape sequences
+ seq gives better diagnostics for invalid formats.
+
** Consistency
mkdir and split now write --verbose output to stdout, not stderr.
diff --git a/TODO b/TODO
index 8c6b6fc..3f4d26c 100644
--- a/TODO
+++ b/TODO
@@ -61,8 +61,6 @@ printf: consider adapting builtins/printf.def from bash
df: add `--total' option, suggested here http://bugs.debian.org/186007
-seq: give better diagnostics for invalid formats:
- e.g. no or too many % directives
seq: consider allowing format string to contain no %-directives
tail: don't use xlseek; it *exits*.
diff --git a/src/seq.c b/src/seq.c
index b073fd1..c7e8cb9 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -177,6 +177,33 @@ scan_arg (const char *arg)
return ret;
}
+/* Validate the format, FMT. Print a diagnostic and exit
+ if there is not exactly one %-directive. */
+
+static void
+validate_format (char const *fmt)
+{
+ unsigned int n_directives = 0;
+ char const *p;
+
+ for (p = fmt; *p; p++)
+{
+ if (p[0] == '%' && p[1] != '%' && p[1] != '\0')
+ {
+ ++n_directives;
+ ++p;
+ }
+}
+ if (! n_directives)
+{
+ error (0, 0, _("no %% directive in format string %s"), quote (fmt));
+ usage (EXIT_FAILURE);
+}
+ else if (1 < n_directives)
+error (EXIT_FAILURE, 0, _("too many %% directives in format string %s"),
+ quote (fmt));
+}
+
/* If FORMAT is a valid printf format for a double argument, return
its long double equivalent, possibly allocated from dynamic
storage, and store into *LAYOUT a description of the output layout;
@@ -405,6 +432,7 @@ main (int argc, char **argv)
if (format_str)
{
+ validate_format (format_str);
char const *f = long_double_format (format_str, &layout);
if (! f)
{
diff --git a/tests/misc/seq b/tests/misc/seq
index 1a153a3..f48289b 100755
--- a/tests/misc/seq
+++ b/tests/misc/seq
@@ -87,10 +87,14 @@ my @Tests =
# "seq: memory exhausted". In coreutils-6.0..6.8, it would mistakenly
# succeed and print a blank line.
['fmt-eos1', qw(-f % 1), {EXIT => 1},
-{ERR => "seq: invalid format string: `%'\n" . $try_help }],
+{ERR => "seq: no % directive in format string `%'\n" . $try_help }],
['fmt-eos2', qw(-f %g% 1), {EXIT => 1},
{ERR => "seq: invalid format string: `%g%'\n" . $try_help }],
+ ['fmt-d', qw(-f "" 1), {EXIT => 1},
+{ERR => "seq: no % directive in format string `'\n" . $try_help }],
+ ['fmt-e', qw(-f %g%g 1), {EXI
Re: [PATCH] Check the order of the input by default, if there are unpairable input lines.
"James Youngman" <[EMAIL PROTECTED]> wrote: > On Feb 18, 2008 11:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> Thanks for pursuing this. >> Same tests as before? > > Yes, one had to be removed (it verified that no oder checking was done > by default). > >> IMHO, it's good to keep them in the same change set. >> >> There are a few trailing blanks, too. >> Repeat after me: "make distcheck", "make distcheck", ... :) > > I can send the changes all again in a single patch (is that what you > meant by "change set"?) and fix the trailing blanks too if you like. Yes, please. then I don't have to figure out which test to remove. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bug in the command "du"
Hallo, i've found a bug in the command "du" When i list recursivly directories and i only want to see the binary count of all files. I become a wrong result. The command e.g. "du -ab" add the bytes from "." in every directory to the result. Or did you have a parameterset to list the bytes only of the files? regards Jochen ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Problems building coreutils HEAD against gnulib HEAD
I found I had been testing with a sufficiently out-of-date gnulib to prevent coreutils' "make dist" from working. I updated it and now "bootstrap" doesn't work :) Should I be using a slightly older version of gnulb to build git coreutils? Is there any mapping between compatible revisions? $ for dir in $(pwd) gnulib; do ( cd $dir && pwd -P && git show-ref HEAD ); echo; done /home/james/source/GNU/coreutils/coreutils b8108fd2ddf77ae79cd014f4f37798a52be13fd1 refs/remotes/origin/HEAD /home/james/source/GNU/coreutils/coreutils/gnulib 82909c26caea8467049abef573cbd3954dc5c444 refs/remotes/origin/HEAD $ ./bootstrap ; echo $? [...] ./bootstrap: m4/lib-link.m4 overrides ._bootmp2/m4/lib-link.m4 ./bootstrap: m4/lib-prefix.m4 overrides ._bootmp2/m4/lib-prefix.m4 ./bootstrap: m4/longlong.m4 overrides ._bootmp2/m4/longlong.m4 ./bootstrap: m4/nls.m4 overrides ._bootmp2/m4/nls.m4 ./bootstrap: m4/po.m4 overrides ._bootmp2/m4/po.m4 ./bootstrap: m4/printf-posix.m4 overrides ._bootmp2/m4/printf-posix.m4 ./bootstrap: m4/progtest.m4 overrides ._bootmp2/m4/progtest.m4 ./bootstrap: m4/size_max.m4 overrides ._bootmp2/m4/size_max.m4 ./bootstrap: m4/stdint_h.m4 overrides ._bootmp2/m4/stdint_h.m4 ./bootstrap: m4/wchar_t.m4 overrides ._bootmp2/m4/wchar_t.m4 ./bootstrap: m4/wint_t.m4 overrides ._bootmp2/m4/wint_t.m4 ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4 ./bootstrap: aclocal --force -I m4 ... aclocal: aclocal: file `m4/isnan.m4' does not exist 1 James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
James Youngman wrote: > I found I had been testing with a sufficiently out-of-date gnulib to > prevent coreutils' "make dist" from working. I updated it and now > "bootstrap" doesn't work :) Building coreutils is somewhat involved because it needs quite new versions of a number of dependencies. It is not as simple as I would like. But having said all of that coreutils is building for me using the latest gnulib. Take a peek. http://buildbot.proulx.com:9000/ > Should I be using a slightly older version of gnulb to build git > coreutils? Is there any mapping between compatible revisions? gnulib often breaks downstream tools but today's version is working for me. > $ for dir in $(pwd) gnulib; do ( cd $dir && pwd -P && git show-ref > HEAD ); echo; done > /home/james/source/GNU/coreutils/coreutils > b8108fd2ddf77ae79cd014f4f37798a52be13fd1 refs/remotes/origin/HEAD > > /home/james/source/GNU/coreutils/coreutils/gnulib > 82909c26caea8467049abef573cbd3954dc5c444 refs/remotes/origin/HEAD Same as the versions here. In addition to standard things I also have autoconf-2.61, automake-70bca13b, gettext-1.16.1, and m4-1.4.8. Those are the versions that are building for me. > ./bootstrap: aclocal --force -I m4 ... > aclocal: aclocal: file `m4/isnan.m4' does not exist > 1 Not sure about that. Perhaps it would help to compare the bootstrap output you are getting to the output here: http://buildbot.proulx.com:9000/amd64%20gnu-linux/builds/7175/step-configure/0 Somewhere there is a system test that is behaving differently. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bob Proulx on 2/18/2008 6:56 PM: |> ./bootstrap: aclocal --force -I m4 ... |> aclocal: aclocal: file `m4/isnan.m4' does not exist |> 1 | | Not sure about that. But I am, having seen it myself. It happens when you have a stale symlink from an older copy of gnulib, but which now points nowhere because the file was renamed in gnulib. gnulib-tool --import automatically deletes such symlinks, but coreutils' bootstrap script does not yet do so. For now, I use: find -L -depth -lname '*' -delete to get the tree back in a workable state after updating gnulib but before re-running ./bootstrap. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuk+j84KuGfSFAYARAqBCAJ97iJ8Z1dflKCKJe9EaYVO4dyvHGgCffLCb MT9aqYRA+JvfA236PgtldII= =aPYb -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
