[PATCH] Implement join --check-order and --nocheck-order.
This is a consolidated patch including all the previous changes,
implementing order checking in join by default. "make distcheck"
works (if I move distcheck-hook from Makefile.am to GNUmakefile).
2008-02-16 James Youngman <[EMAIL PROTECTED]>
* src/join.c: Support --check-order and --nocheck-order.
New variables check_input_order, seen_unpairable and
issued_disorder_warning[]. For --check-order, verify that the
input files are in sorted order. For the default case, check the
order only if there are unpairable lines.
(join): Perform ordering checks after reaching EOF on either
input.
(usage): Mention --check-order and --nocheck-order.
(dupline): Save a copy of the previously-read input line so that
we can detect disorder on the input.
(get_line): Temporarily save a copy of the previous line (by
calling dupline) and check relative ordering (by calling
checkorder) before returning the newly-read line.
(getseq, join): Tell get_line which file we are reading from.
(advance_seq): New function, factoring out some of the code
commonly surrounding calls to getseq.
(checkorder): New function. Verifies that a pair of consecutive
input lines are in sorted order.
* coreutils.texi (join invocation): Document the new options
--check-order and --nocheck-order.
* tests/join/Test.pm (tv): Added tests for --check-order and
--nocheck-order.
Signed-off-by: James Youngman <[EMAIL PROTECTED]>
---
NEWS |3 +
doc/coreutils.texi | 27 ++-
src/join.c | 215
tests/join/Test.pm | 33 -
4 files changed, 242 insertions(+), 36 deletions(-)
diff --git a/NEWS b/NEWS
index bc1b47d..d6afac7 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,9 @@ GNU coreutils NEWS-*-
outline -*-
ls --color no longer outputs unnecessary escape sequences
+ join now verifies that the inputs are in sorted order. This check can
+ be turned off with the --nocheck-order option.
+
** Consistency
mkdir and split now write --verbose output to stdout, not stderr.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 016673a..e8ccb4b 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -5149,10 +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}.
-As a @acronym{GNU} extension, 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
@@ -5169,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;
@@ -5188,6 +5201,12 @@ The program accepts the following options. Also see
@ref{Common options}.
Print a line for each unpairable line in file @var{file-number} (either
@samp{1} or @samp{2}), in addition to the normal output.
[EMAIL PROTECTED] --check-order
+Fail with an error message if either input file is wrongly ordered.
+
[EMAIL PROTECTED] --nocheck-order
+Do not check that both input files are in sorted order. This is the default.
+
@item -e @var{string}
@opindex -e
Replace those output fields that are missing in the input with
diff --git a/src/join.c b/src/join.c
index a6ca7e4..d13bd7a 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_di
Re: Problems building coreutils HEAD against gnulib HEAD
On Feb 19, 2008 3:40 AM, Eric Blake <[EMAIL PROTECTED]> wrote: > 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. Thanks, that fixed it. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Fix check-ls-dircolors for VPATH build.
2008-02-19 James Youngman <[EMAIL PROTECTED]> * Makefile.am (check-ls-dircolors): Look for sources under $(top_srcdir), not under ".". Signed-off-by: James Youngman <[EMAIL PROTECTED]> --- Makefile.am |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index fcf5cfa..8747072 100644 --- a/Makefile.am +++ b/Makefile.am @@ -108,10 +108,12 @@ THANKS-to-translators: po/LINGUAS THANKStt.in # remain in sync. .PHONY: check-ls-dircolors check-ls-dircolors: - dc=$$(sed -n '/static.*ls_codes\[/,/};'/p src/dircolors.c \ + dc=$$(sed -n '/static.*ls_codes\[/,/};'/p \ + $(top_srcdir)/src/dircolors.c \ |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ - ls=$$(sed -n '/static.*indicator_name\[/,/};'/p src/ls.c\ + ls=$$(sed -n '/static.*indicator_name\[/,/};'/\p\ + $(top_srcdir)/src/ls.c \ |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ test "$$dc" = "$$ls" -- 1.5.3.8 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
GNUmakefile missing from build dir in VPATH build
VPATH builds work for me in current coreutils head. However,
"distcheck" gails.
GNUmakefile exists in $(top_srcdir) but not the build directory.
Distcheck does "make distcheck-hook". That's defined in the Makefile
(from $(top_srcdir)/Makefile.am):-
distcheck-hook: check-ls-dircolors
$(MAKE) my-distcheck
Unfortunately my-distcheck is only defined in GNUmakefile, not in
Makefile. So this error results:
[...]
mkdir coreutils-6.10.69-e0b96-dirty/_build
mkdir coreutils-6.10.69-e0b96-dirty/_inst
chmod a-w coreutils-6.10.69-e0b96-dirty
dc_install_base=`CDPATH="${ZSH_VERSION+.}:" && cd
coreutils-6.10.69-e0b96-dirty/_inst && pwd | sed -e
's,^[^:\\/]:[\\/],/,'` \
&& dc_destdir="${TMPDIR-/tmp}/am-dc-$$/" \
&& make distcheck-hook \
&& cd coreutils-6.10.69-e0b96-dirty/_build \
&& ../configure --srcdir=.. --prefix="$dc_install_base" \
\
&& make \
&& make dvi \
&& make check \
&& make install \
&& make installcheck \
&& make uninstall \
&& make distuninstallcheck_dir="$dc_install_base" \
distuninstallcheck \
&& chmod -R a-w "$dc_install_base" \
&& ({ \
(cd ../.. && umask 077 && mkdir "$dc_destdir") \
&& make DESTDIR="$dc_destdir" install \
&& make DESTDIR="$dc_destdir" uninstall \
&& make DESTDIR="$dc_destdir" \
distuninstallcheck_dir="$dc_destdir" distuninstallcheck; \
} || { rm -rf "$dc_destdir"; exit 1; }) \
&& rm -rf "$dc_destdir" \
&& make dist \
&& rm -rf coreutils-6.10.69-e0b96-dirty.tar.gz \
&& make distcleancheck
make[1]: Entering directory `/home/james/source/GNU/coreutils/compile'
dc=$(sed -n '/static.*ls_codes\[/,/};'/p ../coreutils/src/dircolors.c
|sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' |sed -n
's/^"\(..\)"/\1/p'|sort -u); \
ls=$(sed -n '/static.*indicator_name\[/,/};'/\p
../coreutils/src/ls.c |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' |sed
-n 's/^"\(..\)"/\1/p'|sort -u); \
test "$dc" = "$ls"
make my-distcheck
make[2]: Entering directory `/home/james/source/GNU/coreutils/compile'
make[2]: *** No rule to make target `my-distcheck'.
make[2]: Leaving directory `/home/james/source/GNU/coreutils/compile'
make[1]: *** [distcheck-hook] Error 2
make[1]: Leaving directory `/home/james/source/GNU/coreutils/compile'
make: *** [distcheck] Error 2
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
Eric Blake <[EMAIL PROTECTED]> wrote: > 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. Yes, I see it regularly, when switching between git branches that add or remove .m4 files. It's annoying. Didn't someone (you, Eric?) post an automake patch to generate Makefile rules that would avoid this? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Fix check-ls-dircolors for VPATH build.
James Youngman <[EMAIL PROTECTED]> wrote: > 2008-02-19 James Youngman <[EMAIL PROTECTED]> > > * Makefile.am (check-ls-dircolors): Look for sources under > $(top_srcdir), not under ".". Thanks. I've pushed this, retaining backslash alignment and using $(srcdir) rather than $(top_srcdir). Fix non-srcdir "make distcheck" failure. * Makefile.am (check-ls-dircolors): Look for sources under $(srcdir), not under ".". diff --git a/Makefile.am b/Makefile.am index fcf5cfa..67f4934 100644 --- a/Makefile.am +++ b/Makefile.am @@ -108,10 +108,12 @@ THANKS-to-translators: po/LINGUAS THANKStt.in # remain in sync. .PHONY: check-ls-dircolors check-ls-dircolors: - dc=$$(sed -n '/static.*ls_codes\[/,/};'/p src/dircolors.c \ - |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ - |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ - ls=$$(sed -n '/static.*indicator_name\[/,/};'/p src/ls.c\ - |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ - |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ + dc=$$(sed -n '/static.*ls_codes\[/,/};'/p \ + $(srcdir)/src/dircolors.c \ + |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ + |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ + ls=$$(sed -n '/static.*indicator_name\[/,/};'/\p\ + $(srcdir)/src/ls.c \ + |sed -n '/^ *"/p'|tr , '\n'|sed 's/^ *//' \ + |sed -n 's/^"\(..\)"/\1/p'|sort -u); \ test "$$dc" = "$$ls" -- 1.5.4.2.134.g82883 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: GNUmakefile missing from build dir in VPATH build
"James Youngman" <[EMAIL PROTECTED]> wrote: > VPATH builds work for me in current coreutils head. However, > "distcheck" gails. > > GNUmakefile exists in $(top_srcdir) but not the build directory. > Distcheck does "make distcheck-hook". That's defined in the Makefile > (from $(top_srcdir)/Makefile.am):- > > distcheck-hook: check-ls-dircolors > $(MAKE) my-distcheck > > Unfortunately my-distcheck is only defined in GNUmakefile, not in > Makefile. So this error results: Thanks for reporting that. I've known about this problem for a long time, but it hasn't ever seemed worth the trouble of fixing it. Since I invariably run "make distcheck" from the source directory, even if I did fix it, I would rarely exercise that code path. And "make distcheck" takes long enough as it is without adding a second run for a non-srcdir build, that I don't want to automate it that way. But if you're interested, and the changes aren't too invasive, who knows... :-) ___ 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 [adding bug-automake] According to Jim Meyering on 2/19/2008 4:33 AM: |> 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. | | It's annoying. Didn't someone (you, Eric?) post an automake | patch to generate Makefile rules that would avoid this? You are thinking about this patch of Ralf's: http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=d0ebf71 I'm not sure if that was ported back to the 1.10 branch. But it looks like that patch only handles the make rules for rerunning aclocal, and will not impact the ./bootstrap rules for running aclocal afresh when there are broken symlinks matching *.m4 in the included directories. Maybe one more automake patch is needed, to avoid warning on broken symlink source files if the resulting aclocal still manages to provide every needed macro? Meanwhile, I still think coreutils' bootstrap should delete these broken symlinks before trying to run aclocal. - -- 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 iD8DBQFHutmD84KuGfSFAYARAj+JAKCks8FiZ1bXzsLQu0y1YY3w7fPzygCgyxj5 CuMXB3YbUD4i+7UYeO12S34= =5pMJ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in the command "du"
On Mon, 18 Feb 2008, Jochen Röder wrote: 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. This is not a bug. -a is documented to include "all files, not just directories"; its purpose is not to alter the reported totals, but to show more detail by including an output line for every "file" i.e. directory entry, which can be a regular file, directory, symlink etc. Or did you have a parameterset to list the bytes only of the files? Assuming you mean only regular files, there is no option to restrict du's output in this way. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: GNUmakefile missing from build dir in VPATH build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to James Youngman on 2/19/2008 4:53 AM: | GNUmakefile exists in $(top_srcdir) but not the build directory. | Distcheck does "make distcheck-hook". That's defined in the Makefile | (from $(top_srcdir)/Makefile.am):- Shouldn't it be possible for bootstrap and/or configure to create a symlink to GNUMakefile in the build dir that points back to the source dir, if the two directories are not the same? Would this symlink adequately supply all the needed definitions for a distcheck in a VPATH build? - -- 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 iD8DBQFHutvD84KuGfSFAYARAgegAKDJ8zoa/blmpL2EjFqec1zYRukd1wCcD29X QYMqsAjjbyjGnJlJsiBvzZk= =VHly -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Implement join --check-order and --nocheck-order.
James Youngman <[EMAIL PROTECTED]> wrote:
> This is a consolidated patch including all the previous changes,
> implementing order checking in join by default. "make distcheck"
> works (if I move distcheck-hook from Makefile.am to GNUmakefile).
>
> 2008-02-16 James Youngman <[EMAIL PROTECTED]>
>
> * src/join.c: Support --check-order and --nocheck-order.
Thanks.
For future reference, I've made a few changes so far:
The first of which was to get past a "make distcheck" failure:
dupline
the above functions should have static scope
make[1]: *** [sc_tight_scope] Error 1
Then a few spacing/style changes.
Also, I'm going to change this
newline->fields = xmalloc (sizeof *newline->fields * old->nfields_allocated);
to this:
newline->fields = xnmalloc (old->nfields_allocated, sizeof *newline->fields);
No need to resend.
diff --git a/src/join.c b/src/join.c
index 832b3bd..627828e 100644
--- a/src/join.c
+++ b/src/join.c
@@ -260,8 +260,8 @@ xfields (struct line *line)
extract_field (line, ptr, lim - ptr);
}
-struct line*
-dupline (const struct line *old)
+static struct line*
+dup_line (const struct line *old)
{
struct line *newline = xmalloc (sizeof *newline);
size_t i;
@@ -278,7 +278,7 @@ dupline (const struct line *old)
newline->nfields = old->nfields;
newline->nfields_allocated = old->nfields_allocated;
- for (i=0; infields; i++)
+ for (i = 0; i < old->nfields; i++)
{
newline->fields[i].len = old->fields[i].len;
newline->fields[i].beg = newline->buf.buffer + (old->fields[i].beg
@@ -319,12 +319,12 @@ get_line (FILE *fp, struct line *line, int which)
line->fields = NULL;
xfields (line);
- if (prevline[which-1])
+ if (prevline[which - 1])
{
- checkorder (prevline[which-1], line, which);
- freeline (prevline[which-1]);
+ checkorder (prevline[which - 1], line, which);
+ freeline (prevline[which - 1]);
}
- prevline[which-1] = dupline (line);
+ prevline[which - 1] = dup_line (line);
return true;
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Implement join --check-order and --nocheck-order.
James Youngman <[EMAIL PROTECTED]> wrote: > This is a consolidated patch including all the previous changes, > implementing order checking in join by default. "make distcheck" > works (if I move distcheck-hook from Makefile.am to GNUmakefile). > > > 2008-02-16 James Youngman <[EMAIL PROTECTED]> > > * src/join.c: Support --check-order and --nocheck-order. > New variables check_input_order, seen_unpairable and > issued_disorder_warning[]. For --check-order, verify that the ... Thanks again. I've just pushed that. ___ 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: > 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". Thanks again. I've pushed this. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Implement join --check-order and --nocheck-order.
James Youngman wrote: > This is a consolidated patch including all the previous changes, > implementing order checking in join by default. "make distcheck" > works (if I move distcheck-hook from Makefile.am to GNUmakefile). While I like the idea, I'm a little worried about the implementation. You seem to duplicate the buffers rather than the pointers. Do you really need to do the extra malloc() + memcpy() per line read? Could you compare the performance of before and after (with LANG=C). thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
Eric Blake <[EMAIL PROTECTED]> wrote: > [adding bug-automake] > > According to Jim Meyering on 2/19/2008 4:33 AM: > |> 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. > | > | It's annoying. Didn't someone (you, Eric?) post an automake > | patch to generate Makefile rules that would avoid this? > > You are thinking about this patch of Ralf's: > http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=d0ebf71 > > I'm not sure if that was ported back to the 1.10 branch. But it looks > like that patch only handles the make rules for rerunning aclocal, and > will not impact the ./bootstrap rules for running aclocal afresh when > there are broken symlinks matching *.m4 in the included directories. > Maybe one more automake patch is needed, to avoid warning on broken > symlink source files if the resulting aclocal still manages to provide > every needed macro? Meanwhile, I still think coreutils' bootstrap should > delete these broken symlinks before trying to run aclocal. I agree. What do you think of this patch (untested)? It's probably good enough, but I'll bet someone will suggest a more portable version :-) diff --git a/bootstrap b/bootstrap index 7dacfe6..1dd3bc2 100755 --- a/bootstrap +++ b/bootstrap @@ -2,7 +2,7 @@ # Bootstrap this package from checked-out sources. -# Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. +# Copyright (C) 2003-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 @@ -538,6 +538,12 @@ if test -f $mam_template; then done fi +# Remove dangling symlinks in gnulib-populated directories. +# This depends on GNU find, and a relatively recent version at that. +# Ignore any failure for now, since it's only to avoid the relatively +# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed. +find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1 + # Reconfigure, getting other files. for command in \ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[RFC] seq: allow format string to contain no %-directives
I was wondering how such an implementation would possibly look like. But before I dig into the code again, some clarification on the specifics of expected behavior would be regarded helpful. Would such a change allow for repeated items such as $ seq -f "a" 5 a a a a a for example? With following invocation $ ./src/seq -f "a" 5 it currently (with the patched version) results in ./src/seq: no % directive in format string `a' Try `./src/seq --help' for more information. Would it then be considered sensible to introduce a new command-line flag or should we perhaps circumvent this limitation whenever an alphanumeric string is found? PS: I searched the mailing list archive, but there didn't seem to be any previously related discussion on this topic. Steven Schubiger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
Jim Meyering <[EMAIL PROTECTED]> writes: > +# Remove dangling symlinks in gnulib-populated directories. > +# This depends on GNU find, and a relatively recent version at that. > +# Ignore any failure for now, since it's only to avoid the relatively > +# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed. > +find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1 Why do you need -depth? Also, find 4.1 does not support -L nor -delete. A more portable predicate is -xtype l. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] seq: allow format string to contain no %-directives
Steven Schubiger <[EMAIL PROTECTED]> wrote: > I was wondering how such an implementation would possibly look like. > But before I dig into the code again, some clarification on the specifics > of expected behavior would be regarded helpful. > > Would such a change allow for repeated items such as > > $ seq -f "a" 5 > a > a > a > a > a Thanks for looking at it. Actually, I've just removed that TODO item. There are plenty of other ways to print a constant string repeatedly, so changing seq to allow this is not justified. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
Hello, * Eric Blake wrote on Tue, Feb 19, 2008 at 02:28:35PM CET: > [adding bug-automake] > > According to Jim Meyering on 2/19/2008 4:33 AM: > |> 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. > | > | It's annoying. Didn't someone (you, Eric?) post an automake > | patch to generate Makefile rules that would avoid this? > > You are thinking about this patch of Ralf's: > http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=d0ebf71 > > I'm not sure if that was ported back to the 1.10 branch. But it looks > like that patch only handles the make rules for rerunning aclocal, and > will not impact the ./bootstrap rules for running aclocal afresh when > there are broken symlinks matching *.m4 in the included directories. > Maybe one more automake patch is needed, to avoid warning on broken > symlink source files I don't think aclocal should silenctly ignore stale symlinks. I can't imagine a situation in which I wouldn't call stale symlinks a bug in another program, or a mistakenly broken tree. > if the resulting aclocal still manages to provide > every needed macro? Well, aclocal cannot easily detect whether you intended for that local pkg/gnulib/m4/foo.m4 macro to override that installed /usr/share/aclocal/foo.m4 macro file or not. I prefer if such issues do not go silent in any cases we can avoid. > Meanwhile, I still think coreutils' bootstrap should > delete these broken symlinks before trying to run aclocal. I think that's just the proper solution to this issue. And with Automake master, it should also not cause hickups any more. Cheers, Ralf ___ 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 Andreas Schwab on 2/19/2008 8:37 AM: | Jim Meyering <[EMAIL PROTECTED]> writes: | |> +# Remove dangling symlinks in gnulib-populated directories. |> +# This depends on GNU find, and a relatively recent version at that. |> +# Ignore any failure for now, since it's only to avoid the relatively |> +# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed. |> +find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1 | | Why do you need -depth? Also, find 4.1 does not support -L nor -delete. Because -delete implies -depth, and new enough findutils warns and does nothing rather than deleting a possibly different set of files than what you tested with (the use case that prompted the change was something like "find -name '*.txt'" as the dry run, then "find -delete -name '*.txt'" which proceeded to delete everything in `.'). | A more portable predicate is -xtype l. The goal here is not to delete all symlinks, just symlinks that are broken. Under the influence of -L, does -xtype l work like -lname '*' in detecting just the broken symlinks? - -- 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 iD8DBQFHuzgX84KuGfSFAYARAlCmAKDUxWGgIJ8Vy9QxRLbSXf4JdCPvmwCgmgV6 Rb+jT8xFrKlHjTxs0YRM4h4= =Dp4r -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problems building coreutils HEAD against gnulib HEAD
On Feb 19, 2008 8:12 PM, Eric Blake <[EMAIL PROTECTED]> wrote:
> The goal here is not to delete all symlinks, just symlinks that are
> broken. Under the influence of -L, does -xtype l work like -lname '*' in
> detecting just the broken symlinks?
For that you want "find . -depth -type l -xtype l -delete". That is,
a broken symbolic link looks like a link to both a physical and a
logical view. To do the same thing with 4.1.7, use "find . -depth
-type l -xtype l -exec /bin/rm -f {} \;" though in this case the
-depth is not really needed.
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
Eric Blake <[EMAIL PROTECTED]> writes: > According to Andreas Schwab on 2/19/2008 8:37 AM: > | Jim Meyering <[EMAIL PROTECTED]> writes: > | > |> +# Remove dangling symlinks in gnulib-populated directories. > |> +# This depends on GNU find, and a relatively recent version at that. > |> +# Ignore any failure for now, since it's only to avoid the relatively > |> +# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed. > |> +find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1 > | > | Why do you need -depth? Also, find 4.1 does not support -L nor -delete. > > Because -delete implies -depth, and new enough findutils warns and does > nothing rather than deleting a possibly different set of files than what > you tested with (the use case that prompted the change was something like > "find -name '*.txt'" as the dry run, then "find -delete -name '*.txt'" > which proceeded to delete everything in `.'). I don't understand how -depth would have made any difference here. > | A more portable predicate is -xtype l. > > The goal here is not to delete all symlinks, just symlinks that are > broken. That is exactly what -xtype l does. > Under the influence of -L, does -xtype l work like -lname '*' in > detecting just the broken symlinks? You don't use -L of course (it isn't supported by find 4.1 anyway). Note that with -L you would risk walking out of the base directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
