"Dmitry V. Levin" <[EMAIL PROTECTED]> writes:
> Proposed fix for both cases is attached.
Thanks; I installed that too (and added a test case).
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
I installed this miscellaneous set of minor porting changes:
2004-08-11 Paul Eggert <[EMAIL PROTECTED]>
* lib/fts.c (O_DIRECTORY): Define to 0 if the system doesn't define.
* lib/settime.c (settime): Recode to avoid warning with Sun Forte C 6U2.
* lib/xgethostname.c: D
"Robert Dahlem" <[EMAIL PROTECTED]> writes:
> Under ReliantUnix 5.43 wmemchr() and wmemcpy() are not in libc but in libw.
Thanks for the bug report. I'd rather not hassle with -lw if I can
avoid it. We toyed with -lw last year (to get wcslen on Solaris
2.5.1) but if memory served it's not alway
Philip Rowlands <[EMAIL PROTECTED]> writes:
> I don't know the specs to which GNU cp adheres well enough, but I'd be
> surprised if they mandate a sort routine for recursive copying.
POSIX places no requirement here, since these options are an extension to POSIX.
The GNU documentation says that
Hi,
Under ReliantUnix 5.43 wmemchr() and wmemcpy() are not in libc but in libw.
configure should check for this:
AC_CHECK_FUNCS(wmemchr)
if test $ac_cv_func_wmemchr = no; then
AC_CHECK_LIB(w, wmemchr)
fi
AC_CHECK_FUNCS(wmemcpy)
if test $ac_cv_func_wmemcpy = no; then
AC_CHECK_LIB(w, wmemcpy)
On Wed, Aug 11, 2004 at 11:36:54AM +0100, Philip Rowlands wrote:
> OK, so this is a filesystem-dependent issue when using --recursive on
> source and destination directories which both contain hard links.
For what it's worth, I'm using ext3 as well.
Tim.
*/
pgphJncezsYeh.pgp
Description: PGP s
[EMAIL PROTECTED] wrote:
...
> While the 5.1.2 test release fixed my problem, I've been having a
> disturbing problem that until today I could ignore. Specifically, if
> csplit is fed a lot of input (800kb) from stdin, it would sometimes
> corrupt a tiny amount of the output.
>
> E.g. one line was
On Wed, 11 Aug 2004, Tim Waugh wrote:
>Thinking about it, it must be order-specific. But here's the output I
>get:
>
>`2/d/3' -> `1/d/3'
>`2/d/2' -> `1/d/2'
>`2/d/1' -> `1/d/1'
>`2/d/4' -> `1/d/4'
OK, so this is a filesystem-dependent issue when using --recursive on
source and destination direct
On Wed, Aug 11, 2004 at 02:53:11AM +0100, Philip Rowlands wrote:
> On Tue, 10 Aug 2004, Tim Waugh wrote:
>
> >How odd. Is that a patched 5.2.1?
>
> Possibly; it's from an unadulterated Fedora Core 2.
Yes, that's patched. :-) But I also see the problem in Fedora Core 2.
> I tried building fro
Hi,
Please close bug #6047 in Savannah. A fix is already committed to
glibc. (Although I'm submitter, I can't close the bug.)
Regards,
ogi
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Hi,
On Sat, Jun 26, 2004 at 12:06:19AM -0700, Paul Eggert wrote:
> The --target-directory option is documented for 'install', but it's
> not implemented. Here's a patch to implement it. It steals most of
> the code from the changes I've already proposed for cp/ln/mv.
[...]
> @@ -281,15 +329,25 @
On Tue, 10 Aug 2004, Tim Waugh wrote:
>How odd. Is that a patched 5.2.1?
Possibly; it's from an unadulterated Fedora Core 2.
>Here's what I get with unpatched 5.2.1, straight from the tarball:
>
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ./cp --version
>cp (coreutils) 5.2.1
>Written by Torbjorn
Committed.
Ben
signature.asc
Description: OpenPGP digital signature
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Hi,
On Fri, Jul 30, 2004 at 01:12:13AM -0700, Paul Eggert wrote:
> I installed this patch to use bool (and size_t) when possible, instead
> of int. I don't think it fixes any bugs.
I'm afraid it introduces new bugs:
[...]
> /* Set the timestamps of file TO to match those of file FROM.
> - Re
14 matches
Mail list logo
