litte understanding problem with test
Hi, I built automake and ran the testsuite and one test failed (instsh2.test). So I tracked down the error to the execution of 'test ! -w file'. I thought it would check that I don't have write permission to this file. I tried: echo foofile chmod 444 file test ! -w file echo no write permission no output was given back. As I read the man page it tells me that it also checks for the existence of the file. Maybe that's why no output is given back? This confuses me. Best regards, Alex ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: litte understanding problem with test
Alexander Kahl [EMAIL PROTECTED] wrote: echo foofile chmod 444 file test ! -w file echo no write permission no output was given back. It should indeed write no write permission. However, the test program you're using there is probably the built-in one from your shell, and not the one from coreutils. If you want to use a specified binary, invoke it like this, for example: /usr/bin/test ! -w file echo no write permission ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Error from coreutils CVS version
Alexander Kahl [EMAIL PROTECTED] wrote:
gcc -std=gnu99 -I. -march=pentium4 -O2 -pipe -fomit-frame-pointer -s
-fgnu89-inline -c utimecmp.c
In file included from utimecmp.c:33:
utimens.h:2: error: conflicting types for 'futimens'
/tools/include/sys/stat.h:370: error: previous declaration of 'futimens' was
here
make[2]: *** [utimecmp.o] Error 1
make[2]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib'
make: *** [all-recursive] Error 1
using newest glibc from cvs
Thanks for the reports.
The version of futimens used by coreutils (from gnulib)
takes both a file descriptor and a file name, for portability,
so that if your system doesn't support the FD-based functions
it can still do its job by falling back on the filename-based ones.
The first step is to rename the gnulib function (patch below), since
it is trying to do more than glibc's futimens. Then, we can extend
the renamed gnulib function so that it uses glibc's futimens when possible.
For coreutils, the change is trivial:
just s/futimens/gl_futimens/ in each of copy.c and touch.c.
I nearly changed it in gnulib, but since a few other projects (at least
gzip and tar) also use futimens, I'll wait for Paul to sign off.
2007-05-18 Jim Meyering [EMAIL PROTECTED]
* lib/utimens.c (gl_futimens): Rename from futimens,
now that glibc-2.6 declares futimens.
Index: lib/utimens.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/utimens.c,v
retrieving revision 1.14
diff -u -p -r1.14 utimens.c
--- lib/utimens.c 18 Jan 2007 08:33:34 - 1.14
+++ lib/utimens.c 18 May 2007 07:42:56 -
@@ -75,8 +75,8 @@ struct utimbuf
Return 0 on success, -1 (setting errno) on failure. */
int
-futimens (int fd ATTRIBUTE_UNUSED,
- char const *file, struct timespec const timespec[2])
+gl_futimens (int fd ATTRIBUTE_UNUSED,
+char const *file, struct timespec const timespec[2])
{
/* Some Linux-based NFS clients are buggy, and mishandle time stamps
of files in NFS file systems in some cases. We have no
@@ -185,5 +185,5 @@ futimens (int fd ATTRIBUTE_UNUSED,
int
utimens (char const *file, struct timespec const timespec[2])
{
- return futimens (-1, file, timespec);
+ return gl_futimens (-1, file, timespec);
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Glibc-2.6 (was Re: Error from coreutils CVS version)
On 5/18/07, Greg Schafer [EMAIL PROTECTED] wrote: Alexander Kahl wrote: gcc -std=gnu99 -I. -march=pentium4 -O2 -pipe -fomit-frame-pointer -s -fgnu89-inline -c utimecmp.c In file included from utimecmp.c:33: utimens.h:2: error: conflicting types for 'futimens' /tools/include/sys/stat.h:370: error: previous declaration of 'futimens' was here make[2]: *** [utimecmp.o] Error 1 make[2]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib' make: *** [all-recursive] Error 1 using newest glibc from cvs H, Glibc-2.6 is now released and coreutils-6.9 doesn't compile against it because of this error. It seems Glibc has now gained futimens() and it disagrees with the Coreutils implementation. In fact this is probably a gnulib issue. The prototypes for the relevant functions in the current Austin Group draft document are:- int futimens(int fd, const struct timespec times[2]); int utimensat(int fd, const char *path, const struct timespec times[2], int flag); /* flag may contain AT_SYMLINK_NOFOLLOW */ The current gnulib implementation of futimens() is more like utimensat() than the futimens() above, or so a cursory examination leads me to believe. The underlying problem here I suppose is that both gnulib and glibc are tracking an as-yet-not-final standard document. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: command cp
gri grigri wrote: I have no bug, but an missing feature: cp -p ... ... like mkdir -p ... for the case, that I want to copy a file in a yet not existing directory. Try using rsync. It will create the directory. rsync somefile somedir/ It will create somedir and place somefile within it. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: litte understanding problem with test
[EMAIL PROTECTED] wrote: Thanks for your fast answer :) I tried it as user and it works, seems to be a root issue [EMAIL PROTECTED]:/tmp$ echo foofile chmod 444 file test ! -w file echo no write permission no write permission [EMAIL PROTECTED]:/tmp# echo foofile chmod 444 file test ! -w file echo no write permission [EMAIL PROTECTED]:/tmp# Well, it's telling the truth if you're root, since it *can* write that file, in spite of the permission bits. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: litte understanding problem with test
Thanks for your fast answer :) I tried it as user and it works, seems to be a root issue [EMAIL PROTECTED]:/tmp$ echo foofile chmod 444 file test ! -w file echo no write permission no write permission [EMAIL PROTECTED]:/tmp# echo foofile chmod 444 file test ! -w file echo no write permission [EMAIL PROTECTED]:/tmp# Best regards, Alex ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: litte understanding problem with test
[EMAIL PROTECTED] wrote: Thanks for your fast answer :) I tried it as user and it works, seems to be a root issue root, as in the superuser? The user that has write permission for all files on the system? [EMAIL PROTECTED]:/tmp$ echo foofile chmod 444 file test ! -w file echo no write permission no write permission [EMAIL PROTECTED]:/tmp# echo foofile chmod 444 file test ! -w file echo no write permission [EMAIL PROTECTED]:/tmp# Correct. The root user has superuser permissions and can write to all files on the system. (Let's not talk about NFS's root squash nor security enhanced linux nor any of the others. :-) Try it. You will find that as root you can actually write to those files. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort and LC_COLLATE: suggestions for improvement (with patch)
On Fri, 18 May 2007, Jean-Pierre Vial wrote: When one wants to sort a file in which letters are just codes, not meaningfull words, the sort order obtained through LC_COLLATE is very often inadequate. The help suggest to set LC_ALL=C, but this is often inadequate as well in complcated shell scripts. Inadequate in what sense? The script could be phrased something like this: LC_COLLATE=C sort -k2,2 ... which avoids having to set then reset any LC_ environment variables. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
