Mike Frysinger wrote:
> The current libcap flag handler treats any libcap configure option as
> --disable-libcap because it doesn't check $enableval at all. So make
> sure we do the sane thing:
> --disable-libcap -> disable and don't run any tests
> --enable-libcap -> run tests and fail if not f
Eric Blake wrote:
> Now that POSIX 2008 requires ln to support user choice of whether to
> create hard links to symlinks, we can probably get rid of
> ENABLE_HARD_LINK_TO_SYMLINK_WARNING in the ln.c source code.
Yes. Good point.
> I noticed
> this while considering how to implement linkat in gnu
Eric Blake wrote:
> According to Jim Meyering on 9/1/2009 10:34 AM:
>>> Would you mind pushing it to savannah's coreutils.git next branch, to make
>>> the
>>> overall series easier to review, even though it won't be merged prior to
>>> 7.6?
>>
>> Sure. Just did that.
>> Note that the first chang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/1/2009 10:34 AM:
>> Would you mind pushing it to savannah's coreutils.git next branch, to make
>> the
>> overall series easier to review, even though it won't be merged prior to 7.6?
>
> Sure. Just did that.
> Note tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/28/2009 3:40 PM:
> Also, mingw does not provide dirfd and its struct DIR does not have room for
> an
> fd, so gnulib's dirfd replacement currently just returns ENOTSUP (as
> permitted
> by POSIX).
fts handles this okay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now that POSIX 2008 requires ln to support user choice of whether to
create hard links to symlinks, we can probably get rid of
ENABLE_HARD_LINK_TO_SYMLINK_WARNING in the ln.c source code. I noticed
this while considering how to implement linkat in gnu
Philip Rowlands wrote:
> On Sun, 30 Aug 2009, James R. Van Zandt wrote:
>
>
> > For the help text, here are some alternatives:
> >
> >
> > if DEST is a directory, then delete it first
>
>
> This isn't what -T does. If DEST is an empty directory then it's
> overwritten with the rename(2) sys
On Thursday 03 of September 2009 21:31:01 Mike Frysinger wrote:
> The current libcap flag handler treats any libcap configure option as
> --disable-libcap because it doesn't check $enableval at all. So make
> sure we do the sane thing:
> --disable-libcap -> disable and don't run any tests
> --en
The current libcap flag handler treats any libcap configure option as
--disable-libcap because it doesn't check $enableval at all. So make
sure we do the sane thing:
--disable-libcap -> disable and don't run any tests
--enable-libcap -> run tests and fail if not found
-> run tests and warn if
guys, I'm amazed by your lighning-fast reaction!
On Thu, Sep 03, 2009 at 05:29:27PM +0200, Jim Meyering wrote:
> How about this?
>
>-C, --compare compare each pair of source and destination files,
> and\n\
> -in some cases, do not modify the destination at
> al
Thanks to Olivier Fourdan and Ondřej Vašík.
Here's a patch for that bug:
>From e0e8429c2433bd9820f42250236badc585bd9dd7 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 3 Sep 2009 19:36:34 +0200
Subject: [PATCH] df: don't fail due to an unreadable argument
* src/df.c (main): If open or fst
Florian Schlichting wrote:
> the -C (or --compare) option is currently not mentioned in the info
> documentation, and in man page it reads:
>
> compare each pair of source and destination files, and
> in some cases, do not modify the destination at all
>
> That's not very specific, making -
On Sep 3, 2009 10:08am, C de-Avillez wrote:
>
> Interestingly, it works here with the string you used, and fails in the
> following case:
>
> ~ $ for LANG in $(locale -a); do printf "A b\nAA b\nAAA b\n" | sort
> -h|tr -d '\n'; echo; done | uniq -c
> 1 A bAA bAAA b
> 21 AAA bAA bA b
>
On Thu September 3 2009 16:25:07 Jim Meyering wrote:
> I've applied that, updated the log and will push shortly:
Thanks. What's your opinion about change of the wording as Florian proposed?
Kamil
> From a9bc3fc5e15672ac364dccd827265d3cc9d1aa14 Mon Sep 17 00:00:00 2001
> From: Kamil Dudka
> Date: Thu, 3 Sep 2009 14:08:27 +0200
> Subject: [PATCH] install -C: fix bug in the texi documentation
>
> * doc/coreutils.texi: Move the documentation for install --compare (-C)
> option to the right pla
As reported in
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00342.html by
Ernest N. Mamikonyan, cp/mv fails to preserve extended attributes for
read-only source files.
Following patch fixes the issue for me, although maybe it's not perfect
solution. But I don't know about better one a
Pushed to next:
[This entry is for 7.7 but currently resides in the block for 7.6.
Obviously, it will be moved "up" right after release. ]
>From be4517a4c8cc8797251ad7c2703984bfbb11b983 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 3 Sep 2009 16:11:58 +0200
Subject: [PATCH] NEWS: mentio
On Wed, 2009-09-02 at 21:43 +, Pádraig Brady wrote:
> Follow-up Comment #1, bug #27373 (project coreutils):
>
> I can't reproduce this or see anything wrong with the code.
>
> All 720 of my locales work fine:
>
> $ for LANG in $(locale -a); do printf "KnEnMnZn" | ./sort -h | tr -d 'n';
> ech
I suppose this deserves mention in NEWS, too.
Not only does this fix a long-standing performance problem
with rm -r (but not with -f, which is already efficient),
but it makes rm -r behave correctly also for names longer than 8 KiB,
if your system has support for the faccessat system call.
While
Hi Florian,
On Thu September 3 2009 12:36:13 Florian Schlichting wrote:
> Hi,
>
> the -C (or --compare) option is currently not mentioned in the info
> documentation, and in man page it reads:
>
> compare each pair of source and destination files, and
> in some cases, do not modify the des
Hi,
the -C (or --compare) option is currently not mentioned in the info
documentation, and in man page it reads:
compare each pair of source and destination files, and
in some cases, do not modify the destination at all
That's not very specific, making -C effectively unuseable. I found a
21 matches
Mail list logo
