rm -f *.obj exits with error on nonexisting file

Hi I am wondering, I have different versions of rm.exe with exits with error if I use wildcards with -f parameter and there is no file existing. RM:= rm -f We have many clean targets that make $(RM) *.obj on the first rebuild after fetching the source code it is really anoying that we get s

Re: coreutils-6.0: numerous test failures on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > After this is fixed, only dd/misc fails, and tail/tail-tests hangs. Thanks. Your email didn't mention tail/tail-tests after that -- is that problem known and fixed, or should we look into it further? > + dd iflag=nofollow if=dd-sym.20477 count=0 > + fa

Re: coreutils-6.0: test failures on Solaris 7

Bruno Haible <[EMAIL PROTECTED]> writes: > On Solaris 7, building with "cc -O", I get two test failures: Thanks for reporting these. I installed the following, which I hope fixes them. I'd like tests/ls-2/tests to skip only the setuid-etc test if its setup can't be done, but I don't see any eas

Re: coreutils fails on check for "mv": FAIL: no-target-dir

"Jared Martin" <[EMAIL PROTECTED]> writes: > rename("d", "empty")= -1 EBUSY (Device or resource busy) This appears to be the problem: the rename() system call doesn't work on your Red Hat box, if the destination is an empty directory. What sort of file system are you building

Re: coreutils-6.0: numerous test failures on MacOS X

Paul Eggert wrote: > I think this is the right sort of fix, though I'm puzzled as to why > the code set LC_ALL to the empty string in the first place. > ... > Do you recall why they were set to '' back then? Yes, my archives tell me: On 2000-10-15, I sent Jim a mail, reporting testsuite failures,

Re: coreutils fails on check for "mv": FAIL: no-target-dir

Thanks for the response Paul, I've done as you've requested. I probably should mention what the log files make obvious: I'm not root and I'm installing coreutils in a private directory. Now it occurs to me that perhaps my binutils is not hitting on all eight cylinders, but that is extraneous to y

Re: coreutils-6.0: numerous test failures on MacOS X

Bruno Haible <[EMAIL PROTECTED]> writes: > 2006-08-16 Bruno Haible <[EMAIL PROTECTED]> > > * tests/lang-default: Set LC_ALL to "C", not empty. I think this is the right sort of fix, though I'm puzzled as to why the code set LC_ALL to the empty string in the first place. This dates back t

printing plural values outside unsigned long int range

Here are proposed patches to the gettext manual to address some of the problems I ran into with coreutils (which I mentioned in the message I sent out just a minute ago or so). It'd be nice to have an ngettext variant that works for uintmax_t (and even intmax_t and/or long double, so long as I'm a

Re: hu.po ngettext fixes

In the thread rooted at Koblinger Egmont <[EMAIL PROTECTED]> writes: > What is the correct approach if the number isn't presented in the string, as > in his "This item" vs. "These items" case? Should ngettext be used in this >

Re: [PATCH] coreutils-6.0 memcoll fix

Pádraig Brady <[EMAIL PROTECTED]> writes: > The following obvious patch is needed for the memcoll change in 6.0. Thanks, I applied it. Eric Blake <[EMAIL PROTECTED]> writes: > I guess we did document in memcoll.c that memcoll explicitly sets > errno to 0 on success, making memcoll not quite lik

coreutils-6.0: test failures on Solaris 7

Hi, On Solaris 7, building with "cc -O", I get two test failures: chmod/setgid fails Here are details: $ VERBOSE=yes gmake check TESTS=setgid gmake check-TESTS gmake[1]: Entering directory `/opt/coreutils-6.0/tests/chmod'

Re: coreutils 6.0

On Wed, Aug 16, 2006 at 11:38:28AM +0200, Jim Meyering wrote: Ok. Then I'll use a more robust test for file system type. This also relaxes the test to run if "." is an ext2 file system. Does this patch solve the problem? looks like it Mike Stone _

coreutils-6.0: compilation failure with c89 compiler

Hi, The c99-to-c89.diff mentioned in the announcement is not enough to build with Solaris cc on Solaris 7. I get an error source='fts.c' object='fts.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \ cc -O -DHAVE_CONFIG_H -DLIBDIR=\"/nfs/visu/telecom/users/haible/gnu/arch

Re: coreutils-6.0: "make" output on MacOS X

Bruno Haible <[EMAIL PROTECTED]> wrote: > The problem is the gzip call in Makefile.maint. "make" is GNU make 3.79. > "gzip" is 1.2.4, and it prints --help output to stderr. > > The appended patch fixes the problem. > > Bruno > > > 2006-08-16 Bruno Haible <[EMAIL PROTECTED]> > > * Makefile.m

Re: [PATCH] coreutils-6.0 memcoll fix

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 8/16/2006 2:50 AM: > +++ memcoll-errno.c 2006-08-16 06:50:28.0 + > @@ -43,7 +43,10 @@ > the buffers using strcoll on each substring. */ > >if (s1len == s2len && memcmp (s1, s2, s1len) == 0) > -

Re: coreutils-6.0: two testsuite problems on Linux/x86

Bruno Haible <[EMAIL PROTECTED]> wrote: > On Linux/x86 (Linux 2.4.21, glibc-2.3.6) I get: > > make[3]: Entering directory `/build/coreutils-6.0/tests/dd' > dd iflag=noatime updated atime; O_NOATIME bug in your kernel? > FAIL: misc > > Your announcement says that O_NOATIME is only supported in Linu

coreutils-6.0: "make" output on MacOS X

Building coreutils-6.0 on MacOS X 10.3.9 (Darwin 7.9): configure runs fine; then $ make gzip 1.2.4 (18 Aug 93) usage: gzip [-cdfhlLnNrtvV19] [-S suffix] [file ...] -c --stdout write on standard output, keep original files unchanged -d --decompress decompress -f --force force overwrit

coreutils-6.0: two testsuite problems on Linux/x86

On Linux/x86 (Linux 2.4.21, glibc-2.3.6) I get: make[3]: Entering directory `/build/coreutils-6.0/tests/dd' dd iflag=noatime updated atime; O_NOATIME bug in your kernel? FAIL: misc Your announcement says that O_NOATIME is only supported in Linux >= 2.6.8. So this should be an XFAIL, not a FAIL, a

Re: hu.po ngettext fixes

On Tue, Aug 15, 2006 at 01:59:40PM -0700, Paul Eggert wrote: Hi, > Can you please forward that patch to the Translation Project? Done. > This is apparently an error in general, since Hungarian has two plural > forms when there is no numeral involved; please see the discussion at >

Re: coreutils 6.0: fix portability problem in acl test

Andreas Schwab <[EMAIL PROTECTED]> wrote: > The == operator is not a portable test operator, it should be = instead. > > 2006-08-16 Andreas Schwab <[EMAIL PROTECTED]> > > * tests/cp/acl: Don't use non-portable == operator for test. Applied. Thanks. __

coreutils 6.0: fix portability problem in acl test

The == operator is not a portable test operator, it should be = instead. Andreas. 2006-08-16 Andreas Schwab <[EMAIL PROTECTED]> * tests/cp/acl: Don't use non-portable == operator for test. --- tests/cp/acl.~1.5.~ 2005-11-17 22:17:35.0 +0100 +++ tests/cp/acl2006-08-16 1

Re: coreutils 6.0

Michael Stone <[EMAIL PROTECTED]> wrote: > On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote: >>What version of Linux is that? > > 2.6.17 > >>From the name of the directory, it's probably a tmpfs file system. > > actually it's xfs. it's inside a pbuilder chroot, so the mtab is going > t

Re: coreutils 6.0

On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote: What version of Linux is that? 2.6.17 From the name of the directory, it's probably a tmpfs file system. actually it's xfs. it's inside a pbuilder chroot, so the mtab is going to be completely bogus (I think mount would report /

Re: coreutils 6.0, Solaris 9 build failure

On Tue 06-08-15 22:12, Paul Eggert wrote: > Keith Thompson <[EMAIL PROTECTED]> writes: > > > I got the same error with gcc 4.1.1. > > Are you building GCC with the Sun linker, or with the binutils linker? > I'm doing the former, and that might be related to the problem. Not > that I think it mat

[PATCH] coreutils-6.0 memcoll fix

Sorry Paul. The following obvious patch is needed for the memcoll change in 6.0. I didn't notice it in my quick test as I had forgotten I changed xmemcoll to memcoll in uniq in my tree. I only noticed errno being non zero for me when I redirect uniq to >/dev/null but I guess there are a million o