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
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,
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
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
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
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).
-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.
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
-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
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]
*
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]
*
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
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
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.
|
|
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
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
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
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
|
-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
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
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
21 matches
Mail list logo
