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 --n
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 symli
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 syml
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_srcdi
"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)/Makefi
-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 gnuli
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 bu
-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 possibl
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
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 gnu
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 followin
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
>
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 fa
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 an
22 matches
Mail list logo
