removing redundant -I options from src/Makefile
I installed this: 2006-08-26 Paul Eggert [EMAIL PROTECTED] * src/Makefile.am (AM_CPPFLAGS): Remove -I$(srcdir) and -I../lib, since Automake supplies them for us. It always did -I$(srcdir), and with the recent change to AC_CONFIG_HEADERS in configure.ac it is now also doing -I../lib. --- src/Makefile.am 25 Aug 2006 23:30:59 - 1.74 +++ src/Makefile.am 27 Aug 2006 05:57:59 - @@ -51,7 +51,7 @@ EXTRA_DIST = dcgen dircolors.hin tac-pip BUILT_SOURCES = CLEANFILES = $(SCRIPTS) su -AM_CPPFLAGS = -I$(srcdir) -I$(top_srcdir)/lib -I../lib +AM_CPPFLAGS = -I$(top_srcdir)/lib # Sometimes, the expansion of $(LIBINTL) includes -lc which may # include modules defining variables like `optind', so libcoreutils.a ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
../ paths vs top_builddir
along the lines of the previous commits, is there a reason src/Makefile.am uses ../lib/lib*.a instead of $(top_builddir)/lib/lib*.a ? i'm looking at LDADD and $(PROGRAMS) ... -mike pgpfSdIxKEcmZ.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ../ paths vs top_builddir
Mike Frysinger [EMAIL PROTECTED] wrote: along the lines of the previous commits, is there a reason src/Makefile.am uses ../lib/lib*.a instead of $(top_builddir)/lib/lib*.a ? i'm looking at LDADD and $(PROGRAMS) ... Yes. I find .. to be more readable than the otherwise equivalent-in-src/ $(top_builddir). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
xnanosleep range with 64 bit time_t
lib/xnanosleep.c currently assumes nanosleep works with any value that can be fit into the struct timespec. For gnu+linux on a platform with 64 bit longs, this isn't true (it currently doesn't even return and error but just silently integer-overflows, but I've submitted a patch to make it error). I haven't checked how other operating systems handle this (do any others even have 64 bit time_t's?), but the follow patch stops it from failing silently on linux, and if and when my patch is accepted, it stops it from erroring. If there are other operating systems the coreutils run on that handle 64 bit time_t's properly this should be #ifdef linux-ed, but I'll leave that to someone who knows more about the build system. --- coreutils/lib/xnanosleep.c.old 2006-08-27 10:49:11.0 +0200 +++ coreutils/lib/xnanosleep.c 2006-08-27 11:40:25.0 +0200 @@ -34,9 +34,10 @@ #include intprops.h #include timespec.h +#include minmax.h #ifndef TIME_T_MAX -# define TIME_T_MAX TYPE_MAXIMUM (time_t) +# define TIME_T_MAX MIN(TYPE_MAXIMUM (time_t), (~(131))) #endif /* Sleep until the time (call it WAKE_UP_TIME) specified as -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
I should add this patch is against current CVS. xnanosleep.c hasn't changed much recently, but minmax.h is new. -- Frank v Waveren Key fingerprint: BDD7 D61E [EMAIL PROTECTED] 5D39 CF05 4BFC F57A Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8 signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17540] cp: cannot backup `./.': Device or resource busy
Andreas Schwab [EMAIL PROTECTED] wrote:
Summary: cp: cannot backup `./.': Device or resource busy
Project: GNU Core Utilities
...
$ cp --version | head -1
cp (GNU coreutils) 6.2-cvs
$ mkdir x y
$ cd y
$ cp -ab ../x/. .
cp: cannot backup `./.': Device or resource busy
Thanks for reporting that.
I've fixed it like this:
2006-08-27 Jim Meyering [EMAIL PROTECTED]
* src/copy.c (copy_internal): Don't make a backup if the last
component of the source name is . or ...
Reported by Andreas Schwab in https://savannah.gnu.org/bugs/?17540.
* tests/cp/src-base-dot: New file. Test for the above fix.
* tests/cp/Makefile.am (TESTS): Add src-base-dot.
* src/system.h (DOT_OR_DOTDOT): Remove macro. Rewrite as a...
(dot_or_dotdot): ...new static inline function.
* src/remove.c (rm_1): Reflect this renaming.
* src/ls.c (basename_is_dot_or_dotdot): Likewise.
Index: src/system.h
===
RCS file: /fetish/cu/src/system.h,v
retrieving revision 1.155
diff -u -r1.155 system.h
--- src/system.h25 Aug 2006 23:30:59 - 1.155
+++ src/system.h27 Aug 2006 16:36:57 -
@@ -447,9 +447,14 @@
#include unlocked-io.h
#include same-inode.h
-#define DOT_OR_DOTDOT(Basename) \
- (Basename[0] == '.' (Basename[1] == '\0' \
- || (Basename[1] == '.' Basename[2] == '\0')))
+static inline bool
+dot_or_dotdot (char const *file_name)
+{
+ return (file_name[0] == '.'
+ (file_name[1] == '\0'
+ || (file_name[1] == '.'
+ file_name[2] == '\0')));
+}
/* A wrapper for readdir so that callers don't see entries for `.' or `..'. */
static inline struct dirent const *
@@ -458,7 +463,7 @@
while (1)
{
struct dirent const *dp = readdir (dirp);
- if (dp == NULL || ! DOT_OR_DOTDOT (dp-d_name))
+ if (dp == NULL || ! dot_or_dotdot (dp-d_name))
return dp;
}
}
Index: src/remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.156
diff -u -r1.156 remove.c
--- src/remove.c3 Jul 2006 17:38:20 - 1.156
+++ src/remove.c27 Aug 2006 16:37:58 -
@@ -1372,7 +1372,7 @@
struct rm_options const *x, int *cwd_errno)
{
char const *base = last_component (filename);
- if (DOT_OR_DOTDOT (base))
+ if (dot_or_dotdot (base))
{
error (0, 0, _(cannot remove `.' or `..'));
return RM_ERROR;
Index: src/ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.439
diff -u -r1.439 ls.c
--- src/ls.c26 Aug 2006 06:46:17 - 1.439
+++ src/ls.c27 Aug 2006 16:38:41 -
@@ -2814,7 +2814,7 @@
basename_is_dot_or_dotdot (const char *name)
{
char const *base = last_component (name);
- return DOT_OR_DOTDOT (base);
+ return dot_or_dotdot (base);
}
/* Remove any entries from FILES that are for directories,
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.208
diff -u -r1.208 copy.c
--- src/copy.c 27 Aug 2006 16:29:11 - 1.208
+++ src/copy.c 27 Aug 2006 16:44:02 -
@@ -1185,7 +1185,10 @@
}
}
- if (x-backup_type != no_backups)
+ if (x-backup_type != no_backups
+ /* Don't try to back up a destination if the last
+component of src_name is . or ... */
+ ! dot_or_dotdot (last_component (src_name)))
{
char *tmp_backup = find_backup_file_name (dst_name,
x-backup_type);
Index: tests/cp/src-base-dot
===
RCS file: tests/cp/src-base-dot
diff -N tests/cp/src-base-dot
--- /dev/null 1 Jan 1970 00:00:00 -
+++ tests/cp/src-base-dot 27 Aug 2006 19:39:59 -
@@ -0,0 +1,54 @@
+#!/bin/sh
+# Ensure that mkdir x y; cd y; cp -ab ../x/. . is a successful, silent,
no-op.
+
+# Copyright (C) 2006 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+if test $VERBOSE = yes; then
+ set -x
+
[bug #17540] cp: cannot backup `./.': Device or resource busy
Update of bug #17540 (project coreutils): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for the report. I've checked in a fix for this. Details here: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/7943 ___ Reply to this item at: http://savannah.gnu.org/bugs/?17540 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
hi, can you guide me how can i determine that my hardware is 32-bit or 64-bit and i am using linux. regards ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
