Re: xnanosleep range with 64 bit time_t
Frank v Waveren [EMAIL PROTECTED] writes: I haven't checked how other operating systems handle this (do any others even have 64 bit time_t's?) Yes, pretty much every operating system with 64-bit long has 64-bit time_t, which means most OSes these days (at least on some platform). So we can't install that patch as-is: it would break things on too many platforms. 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). That doesn't sound right. Why not just fix nanosleep so that it works instead? It shouldn't be that hard. There shouldn't be an arbitrary upper bound to the length of the sleep. Also, until the kernel bug gets fixed, what's the harm of leaving coreutils alone? The bug occurs only for sleeps longer than about 68 years, so it's not like this is a burning issue. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
determining 64-bit hardware [was: (no subject)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please use a descriptive subject line; otherwise your mail is more likely to end up in junk mail filters. According to deepesh chaudhary on 8/27/2006 5:43 PM: hi, can you guide me how can i determine that my hardware is 32-bit or 64-bit and i am using linux. regards Try uname -m, and see if the machine it lists is a 32-bit platform or 64-bit platform. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE8t4X84KuGfSFAYARAgRSAJ9Epntfgo91HeOhLePRxkU4adD//ACgllUr mZuQHgFU0KZ2zWoVkC+ptYg= =Nqps -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0: numerous test failures on MacOS X
+ dd iflag=nofollow if=dd-sym.20477 count=0
+ fail=1
...
It seems that the nofollow test doesn't work?
What does ktrace tell you about the system calls that were executed?
I assume MacOS X has ktrace?
cd src
ln -s dd.c sym
ktrace ./dd iflag=nofollow if=sym count=0
kdump
Mine says:
8552 dd CALL open(0xbb57,0x100,0)
8552 dd NAMI sym
8552 dd RET open 0
and 0x100 is indeed the value of O_NOFOLLOW in sys/fcntl.h. So it appears
that O_NOFOLLOW exists but has no effect.
Shouldn't be too hard to write a configure against it.
Your email didn't mention tail/tail-tests after that
$ VERBOSE=yes make check
...
passed obs-plus-c1(_POSIX2_VERSION=199209:F)
passed obs-plus-c1(_POSIX2_VERSION=199209:|)
passed obs-plus-c1(_POSIX2_VERSION=199209:)
passed obs-plus-c2(_POSIX2_VERSION=199209:F)
passed obs-plus-c2(_POSIX2_VERSION=199209:|)
passed obs-plus-c2(_POSIX2_VERSION=199209:)
passed obs-c3(F)
passed obs-c3(|)
passed obs-c3()
passed obs-c4(F)
passed obs-c4(|)
passed obs-c4()
passed obs-c5(F)
passed obs-c5(|)
passed obs-c5()
passed obs-l1(F)
passed obs-l1(|)
passed obs-l1()
passed obs-l2(F)
passed obs-l2(|)
passed obs-l2()
passed obs-l3(F)
passed obs-l3(|)
passed obs-l3()
passed obs-plus-l4(_POSIX2_VERSION=199209:F)
passed obs-plus-l4(_POSIX2_VERSION=199209:|)
passed obs-plus-l4(_POSIX2_VERSION=199209:)
passed obs-plus-l5(_POSIX2_VERSION=199209:F)
passed obs-plus-l5(_POSIX2_VERSION=199209:|)
passed obs-plus-l5(_POSIX2_VERSION=199209:)
passed obs-1(F)
passed obs-1(|)
passed obs-1()
passed obs-2(F)
passed obs-2(|)
passed obs-2()
passed obs-3(F)
passed obs-3(|)
passed obs-3()
passed obs-plus-4(_POSIX2_VERSION=199209:F)
passed obs-plus-4(_POSIX2_VERSION=199209:|)
passed obs-plus-4(_POSIX2_VERSION=199209:)
passed obs-plus-5(_POSIX2_VERSION=199209:F)
passed obs-plus-5(_POSIX2_VERSION=199209:|)
passed obs-plus-5(_POSIX2_VERSION=199209:)
passed obs-plus-x1(_POSIX2_VERSION=199209:F)
passed obs-plus-x1(_POSIX2_VERSION=199209:|)
passed obs-plus-x1(_POSIX2_VERSION=199209:)
passed obs-plus-x2(_POSIX2_VERSION=199209:F)
passed obs-plus-x2(_POSIX2_VERSION=199209:|)
passed obs-plus-x2(_POSIX2_VERSION=199209:)
passed obs-l(F)
passed obs-l(|)
passed obs-l()
passed obs-b(F)
passed obs-b(|)
passed obs-b()
passed err-1(|)
passed err-1()
passed err-2(F)
passed err-2(|)
passed err-2()
passed err-3(|)
passed err-3()
passed err-4(F)
passed err-4(|)
passed err-4()
passed err-5(F)
passed err-5(|)
passed err-5()
passed err-6(_POSIX2_VERSION=200112:F)
passed err-6(_POSIX2_VERSION=200112:|)
passed err-6(_POSIX2_VERSION=200112:)
passed minus-1(_POSIX2_VERSION=199209:|)
passed minus-1(_POSIX2_VERSION=199209:)
passed minus-2(_POSIX2_VERSION=199209:|)
passed minus-2(_POSIX2_VERSION=199209:)
passed c-2(_POSIX2_VERSION=200112:F)
passed c-2(_POSIX2_VERSION=200112:|)
passed c-2(_POSIX2_VERSION=200112:)
passed c-2-minus(F)
passed c-2-minus(|)
passed c-2-minus()
passed c2(F)
passed c2(|)
passed c2()
passed c2-minus(F)
passed c2-minus(|)
passed c2-minus()
passed n-1(F)
passed n-1(|)
passed n-1()
passed n-2(F)
passed n-2(|)
passed n-2()
passed n-3(F)
passed n-3(|)
passed n-3()
passed n-4(F)
passed n-4(|)
passed n-4()
passed n-4a(F)
passed n-4a(|)
passed n-4a()
passed n-5(F)
passed n-5(|)
passed n-5()
passed n-5a(F)
passed n-5a(|)
passed n-5a()
passed n-5b(F)
passed n-5b(|)
passed n-5b()
The process that hangs has the command line tail -f -n 1. The debugger
backtrace is:
#0 0x9647f808 in clock_sleep_trap ()
#1 0x9647a9f8 in nanosleep ()
#2 0x8dc8 in xnanosleep (seconds=0) at xnanosleep.c:101
#3 0x46b0 in tail_forever (f=0x300930, nfiles=1, sleep_interval=1) at
tail.c:1105
#4 0x595c in main (argc=9, argv=0x1) at tail.c:1689
In frame #2:
(gdb) print ts_sleep
$1 = {
tv_sec = 1,
tv_nsec = 0
}
Single-stepping with next yields a loop in tail.c:
988 bool any_input = false;
(gdb)
990 for (i = 0; i nfiles; i++)
(gdb)
998 if (f[i].ignore)
(gdb)
1001 if (f[i].fd 0)
(gdb)
1008 name = pretty_name (f[i]);
(gdb)
1011 if (f[i].blocking != blocking)
(gdb)
1008 name = pretty_name (f[i]);
(gdb)
1009 mode = f[i].mode;
(gdb)
1011 if (f[i].blocking != blocking)
(gdb)
1033 if (!f[i].blocking)
(gdb)
1083 bytes_read = dump_remainder (name, fd,
(gdb)
1086 any_input |= (bytes_read != 0);
(gdb)
1087 f[i].size += bytes_read;
(gdb)
990 for (i = 0; i nfiles; i++)
(gdb)
1090 if (! any_live_files (f, nfiles) ! reopen_inaccessible_files)
(gdb)
1096 if ((!any_input | blocking) fflush (stdout) != 0)
(gdb)
1100 if (!any_input)
(gdb)
1102 if (writer_is_dead)
(gdb)
1105 if (xnanosleep (sleep_interval))
(gdb)
1110 writer_is_dead = (pid != 0
(gdb)
988 bool any_input = false;
(gdb)
990 for (i = 0; i nfiles; i++)
(gdb)
998
Re: coreutils-6.0 on BeOS (6)
Simon Josefsson wrote: The reason is that BeOS does not have PF_INET, only AF_INET, but usually they have the same values. Also it doesn't have PF_UNSPEC. Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find PF_INET or PF_UNSPEC? Maybe they are in some non-standard header. It has neither AF_UNSPEC nor PF_UNSPEC, in no header. + #ifdef PF_UNSPEC /* BeOS lacks PF_UNSPEC. */ if (family == PF_UNSPEC) return true; + #endif I'm not sure this will do the right thing. Usually getaddrinfo is called with hints structure that is zeroed out, and only the relevant flags asserted. If family isn't asserted, it usually means take any family. I see. Then what about this patch? It compiles fine on BeOS. 2006-08-26 Bruno Haible [EMAIL PROTECTED] Simon Josefsson [EMAIL PROTECTED] * getaddrinfo.c (PF_INET, PF_UNSPEC): New macros. *** coreutils-6.2-cvs/lib/getaddrinfo.c 2006-08-26 21:52:06.0 +0200 --- coreutils-6.2-beos/lib/getaddrinfo.c2006-08-26 23:35:16.0 +0200 *** *** 42,47 --- 42,56 #include snprintf.h #include strdup.h + /* BeOS has AF_INET, but not PF_INET. */ + #ifndef PF_INET + # define PF_INET AF_INET + #endif + /* BeOS also lacks PF_UNSPEC. */ + #ifndef PF_UNSPEC + # define PF_UNSPEC 0 + #endif + #if defined _WIN32 || defined __WIN32__ # define WIN32_NATIVE #endif ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (6)
Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: The reason is that BeOS does not have PF_INET, only AF_INET, but usually they have the same values. Also it doesn't have PF_UNSPEC. Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find PF_INET or PF_UNSPEC? Maybe they are in some non-standard header. It has neither AF_UNSPEC nor PF_UNSPEC, in no header. Ok, thanks. + #ifdef PF_UNSPEC /* BeOS lacks PF_UNSPEC. */ if (family == PF_UNSPEC) return true; + #endif I'm not sure this will do the right thing. Usually getaddrinfo is called with hints structure that is zeroed out, and only the relevant flags asserted. If family isn't asserted, it usually means take any family. I see. Then what about this patch? It compiles fine on BeOS. Looks good to me. Please install it. /Simon 2006-08-26 Bruno Haible [EMAIL PROTECTED] Simon Josefsson [EMAIL PROTECTED] * getaddrinfo.c (PF_INET, PF_UNSPEC): New macros. *** coreutils-6.2-cvs/lib/getaddrinfo.c 2006-08-26 21:52:06.0 +0200 --- coreutils-6.2-beos/lib/getaddrinfo.c 2006-08-26 23:35:16.0 +0200 *** *** 42,47 --- 42,56 #include snprintf.h #include strdup.h + /* BeOS has AF_INET, but not PF_INET. */ + #ifndef PF_INET + # define PF_INET AF_INET + #endif + /* BeOS also lacks PF_UNSPEC. */ + #ifndef PF_UNSPEC + # define PF_UNSPEC 0 + #endif + #if defined _WIN32 || defined __WIN32__ # define WIN32_NATIVE #endif ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Mike Frysinger wrote: On Friday 25 August 2006 11:14, mwoehlke wrote: Ok, thanks. I a: wasn't sure of a macro that would be defined on Linux (is there a list of these things anywhere? echo | gcc -E -dD - -mike Thanks! Unfortunately it doesn't seem to work with all non-GNU compilers, but it's still really useful. :-) -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0 on BeOS (9)
Paul Eggert wrote:
2006-08-23 Paul Eggert [EMAIL PROTECTED]
* src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This
macro was being used without being defined.
Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
stat.c: In function `print_statfs':
stat.c:416: error: incompatible types in initialization
Preprocessed output snippet:
# 416 stat.c
unsigned long long int fsid = statfsbuf-f_fsid;
The reason is that fsid_t is defined like this:
typedef struct fsid { int32_t val[2]; } fsid_t;
The code that tests HAVE_STRUCT_STATXFS_F_FSID___VAL should also have an
alternative that tests HAVE_STRUCT_STATXFS_F_FSID_VAL (and augment stat-prog.m4
accordingly).
Bruno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Paul Eggert wrote: mwoehlke [EMAIL PROTECTED] writes: If #ifdef is OK, this should do it (works for me with 5.97 and 6.1): As I said, I don't really understand dircolors (but I'll go ahead and remark anyway :-). I don't see why the behavior of 'ls' should depend on whether the Linux kernel is used. Shouldn't coreutils 'ls' behave the same way on FreeBSD or Solaris? The *old* behavior depends on the kernel. Although I can't vouch for FreeBSD, I tested on Solaris (both SPARC 2.6 and x86 10) and several other platforms, and in 5.97 / 6.1, Linux was the *only* platform I tested on which it did not work. All of which is in the Savannah comments. I #ifdef'd the change to avoid doing unnecessary work on platforms that work correctly without the extra call. -- Matthew We are Microsoft. You will be assimilated. Resistance is futile. --Badtech ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
inttypes-related changes for coreutils
I installed this: 2006-08-28 Paul Eggert [EMAIL PROTECTED] Adjust to recent gnulib changes for the inttypes module. * bootstrap.conf (gnulib_modules): Remove stdint; add inttypes. (excluded_files): Don't exclude m4/inttypes-h.m4 or m4/inttypes-pri.m4. * src/system.h: Don't bother to include stdint.h, since we can now assume inttypes.h does the equivalent of including stdint.h. Index: bootstrap.conf === RCS file: /fetish/cu/bootstrap.conf,v retrieving revision 1.5 diff -p -u -r1.5 bootstrap.conf --- bootstrap.conf 26 Aug 2006 06:55:57 - 1.5 +++ bootstrap.conf 28 Aug 2006 20:50:13 - @@ -47,14 +47,14 @@ gnulib_modules= getline getloadavg getndelim2 getopt getpagesize getpass-gnu gettext gettime gettimeofday getugroups getusershell gnupload group-member hard-locale hash hash-pjw host-os human idcache - inttostr lchmod lchown lib-ignore linebuffer link-follow + inttostr inttypes lchmod lchown lib-ignore linebuffer link-follow long-options lstat malloc mbswidth md5 memcasecmp mempcpy memrchr mkancesdirs mkdir mkdir-p mkstemp mktime modechange mountlist obstack pathmax perl physmem posixtm posixver putenv quote quotearg raise readlink readtokens readtokens0 readutmp realloc regex rmdir rmdir-errno rpmatch safe-read same save-cwd savedir settime sha1 sig2str ssize_t stat-macros - stat-time stdbool stdint stdlib-safer stpcpy strcase strftime + stat-time stdbool stdlib-safer stpcpy strcase strftime strpbrk strtoimax strtoumax strverscmp timespec tzset unicodeio unistd-safer unlink-busy unlinkdir unlocked-io uptime userspec utimecmp utimens vasprintf verify version-etc-fsf @@ -79,8 +79,6 @@ XGETTEXT_OPTIONS=$XGETTEXT_OPTIONS'\\\ excluded_files=' m4/glibc2.m4 m4/intdiv0.m4 -m4/inttypes-h.m4 -m4/inttypes-pri.m4 m4/lcmessage.m4 m4/lock.m4 m4/printf-posix.m4 Index: src/system.h === RCS file: /fetish/cu/src/system.h,v retrieving revision 1.156 diff -p -u -r1.156 system.h --- src/system.h27 Aug 2006 19:34:28 - 1.156 +++ src/system.h28 Aug 2006 20:50:13 - @@ -328,7 +328,6 @@ enum #include timespec.h #include inttypes.h -#include stdint.h #include ctype.h ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.0: numerous test failures on MacOS X
I installed this patch to coreutils to address the O_DIRECTORY problem; it assumes the new gnulib fcntl module. 2006-08-28 Paul Eggert [EMAIL PROTECTED] Adjust to recent gnulib changes for the gnulib module. * bootstrap.conf (gnulib_modules): Add fcntl. * src/system.h (SEEK_SET, SEEK_CUR, SEEK_END): Remove. Other code is already assuming these macros are defined. (O_DIRECT, O_DIRECTORY, O_DSYNC, O_NDELAY, O_NOATIME, O_NONBLOCK): (O_NOCTTY, O_NOFOLLOW, O_NOLINKS, O_RSYNC, O_SYNC, O_BINARY, O_TEXT): Remove; the fcntl module now handles these. Index: bootstrap.conf === RCS file: /fetish/cu/bootstrap.conf,v retrieving revision 1.6 diff -p -u -r1.6 bootstrap.conf --- bootstrap.conf 28 Aug 2006 20:51:56 - 1.6 +++ bootstrap.conf 28 Aug 2006 23:02:51 - @@ -41,7 +41,7 @@ gnulib_modules= c-strtold calloc canon-host canonicalize chown cloexec config-h configmake closeout cycle-check d-ino d-type diacrit dirfd dirname dup2 - error euidaccess exclude exitfail fcntl-safer fdl file-type + error euidaccess exclude exitfail fcntl fcntl-safer fdl file-type fileblocks filemode filenamecat fnmatch-gnu fopen-safer fprintftime fsusage ftruncate fts getdate getgroups gethrxtime getline getloadavg getndelim2 getopt getpagesize getpass-gnu Index: src/system.h === RCS file: /fetish/cu/src/system.h,v retrieving revision 1.157 diff -p -u -r1.157 system.h --- src/system.h28 Aug 2006 20:51:56 - 1.157 +++ src/system.h28 Aug 2006 23:02:52 - @@ -152,11 +152,6 @@ initialize_exit_failure (int status) #include fcntl.h -#if !defined SEEK_SET -# define SEEK_SET 0 -# define SEEK_CUR 1 -# define SEEK_END 2 -#endif #ifndef F_OK # define F_OK 0 # define X_OK 1 @@ -164,74 +159,6 @@ initialize_exit_failure (int status) # define R_OK 4 #endif -#if !defined O_DIRECT defined O_DIRECTIO -/* Tru64 spells it `O_DIRECTIO'. */ -# define O_DIRECT O_DIRECTIO -#endif - -#if !defined O_DIRECT -# define O_DIRECT 0 -#endif - -#if !defined O_DIRECTORY -# define O_DIRECTORY 0 -#endif - -#if !defined O_DSYNC -# define O_DSYNC 0 -#endif - -#if !defined O_NDELAY -# define O_NDELAY 0 -#endif - -#if !defined O_NOATIME -# define O_NOATIME 0 -#endif - -#if !defined O_NONBLOCK -# define O_NONBLOCK O_NDELAY -#endif - -#if !defined O_NOCTTY -# define O_NOCTTY 0 -#endif - -#if !defined O_NOFOLLOW -# define O_NOFOLLOW 0 -#endif - -#if !defined O_NOLINKS -# define O_NOLINKS 0 -#endif - -#if !defined O_RSYNC -# define O_RSYNC 0 -#endif - -#if !defined O_SYNC -# define O_SYNC 0 -#endif - -/* For systems that distinguish between text and binary I/O. - O_BINARY is usually declared in fcntl.h */ -#if !defined O_BINARY defined _O_BINARY - /* For MSC-compatible compilers. */ -# define O_BINARY _O_BINARY -# define O_TEXT _O_TEXT -#endif - -#ifdef __BEOS__ - /* BeOS 5 has O_BINARY and O_TEXT, but they have no effect. */ -# undef O_BINARY -# undef O_TEXT -#endif - -#ifndef O_BINARY -# define O_BINARY 0 -# define O_TEXT 0 -#endif - #include dirent.h #ifndef _D_EXACT_NAMLEN # define _D_EXACT_NAMLEN(dp) strlen ((dp)-d_name) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
minor code cleanup from using stat-macros.h
I installed this:
2006-08-28 Paul Eggert [EMAIL PROTECTED]
* src/copy.c (copy_internal): Don't test whether macros like
S_ISLNK are defined, since they're always defined now.
* src/cp.c (main): Likewise.
* src/ln.c (main): Likewise.
* src/ls.c (get_link_name, make_link_name): Likewise.
* src/mkfifo.c (usage): Likewise.
* src/who.c (S_IWGRP): Likewise.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.209
diff -p -u -r1.209 copy.c
--- src/copy.c 27 Aug 2006 19:41:04 - 1.209
+++ src/copy.c 28 Aug 2006 23:25:06 -
@@ -1558,7 +1558,6 @@ copy_internal (char const *src_name, cha
delayed_ok = false;
}
}
-#ifdef S_ISLNK
else if (x-symbolic_link)
{
preserve_metadata = false;
@@ -1597,7 +1596,6 @@ copy_internal (char const *src_name, cha
goto un_backup;
}
}
-#endif
else if (x-hard_link
#ifdef LINK_FOLLOWS_SYMLINKS
@@ -1632,9 +1630,7 @@ copy_internal (char const *src_name, cha
if (! copy_reg (src_name, dst_name, x, src_mode, new_dst, src_sb))
goto un_backup;
}
- else
-#ifdef S_ISFIFO
- if (S_ISFIFO (src_type))
+ else if (S_ISFIFO (src_type))
{
if (mkfifo (dst_name, src_mode))
{
@@ -1642,10 +1638,7 @@ copy_internal (char const *src_name, cha
goto un_backup;
}
}
- else
-#endif
-if (S_ISBLK (src_type) || S_ISCHR (src_type)
- || S_ISSOCK (src_type))
+ else if (S_ISBLK (src_type) || S_ISCHR (src_type) || S_ISSOCK (src_type))
{
if (mknod (dst_name, src_mode, src_sb.st_rdev))
{
@@ -1654,9 +1647,7 @@ copy_internal (char const *src_name, cha
goto un_backup;
}
}
- else
-#ifdef S_ISLNK
- if (S_ISLNK (src_type))
+ else if (S_ISLNK (src_type))
{
char *src_link_val = xreadlink (src_name, src_sb.st_size);
if (src_link_val == NULL)
@@ -1700,7 +1691,7 @@ copy_internal (char const *src_name, cha
{
/* Preserve the owner and group of the just-`copied'
symbolic link, if possible. */
-# if HAVE_LCHOWN
+#if HAVE_LCHOWN
if (lchown (dst_name, src_sb.st_uid, src_sb.st_gid) != 0
! chown_failure_ok (x))
{
@@ -1708,16 +1699,15 @@ copy_internal (char const *src_name, cha
dst_name);
goto un_backup;
}
-# else
+#else
/* Can't preserve ownership of symlinks.
FIXME: maybe give a warning or even error for symlinks
in directories with the sticky bit set -- there, not
preserving owner/group is a potential security problem. */
-# endif
+#endif
}
}
else
-#endif
{
error (0, 0, _(%s has unknown file type), quote (src_name));
goto un_backup;
Index: src/cp.c
===
RCS file: /fetish/cu/src/cp.c,v
retrieving revision 1.221
diff -p -u -r1.221 cp.c
--- src/cp.c15 May 2006 20:19:02 - 1.221
+++ src/cp.c28 Aug 2006 23:25:07 -
@@ -957,12 +957,7 @@ main (int argc, char **argv)
break;
case 's':
-#ifdef S_ISLNK
x.symbolic_link = true;
-#else
- error (EXIT_FAILURE, 0,
-_(symbolic links are not supported on this system));
-#endif
break;
case 't':
Index: src/ln.c
===
RCS file: /fetish/cu/src/ln.c,v
retrieving revision 1.158
diff -p -u -r1.158 ln.c
--- src/ln.c1 Jul 2006 07:04:52 - 1.158
+++ src/ln.c28 Aug 2006 23:25:07 -
@@ -428,12 +428,7 @@ main (int argc, char **argv)
dereference_dest_dir_symlinks = false;
break;
case 's':
-#ifdef S_ISLNK
symbolic_link = true;
-#else
- error (EXIT_FAILURE, 0,
-_(symbolic links are not supported on this system));
-#endif
break;
case 't':
if (target_directory)
Index: src/ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.440
diff -p -u -r1.440 ls.c
--- src/ls.c27 Aug 2006 19:34:28 - 1.440
+++ src/ls.c28 Aug 2006 23:25:08 -
@@ -2760,9 +2760,6 @@ is_directory (const struct fileinfo *f)
return f-filetype == directory || f-filetype == arg_directory;
}
-
-#ifdef S_ISLNK
-
/* Put the name of the file that FILENAME is a symbolic link to
into the LINKNAME field of `f'. COMMAND_LINE_ARG indicates whether
FILENAME is a command-line argument. */
@@ -2805,7 +2802,6 @@ make_link_name (char const *name, char c
strcpy (linkbuf + bufsiz, linkname);
return linkbuf;
}
-#endif
/* Return true if the last component of NAME is `.' or `..'
This is so we don't try to recurse on `././././. ...' */
Index: src/mkfifo.c
Suggested change to tee manpage to show usefulness
--- tee.1 2005-06-06 00:11:04.0 -0700 +++ tee.1.new 2005-06-06 00:09:16.0 -0700 @@ -8,7 +8,7 @@ .SH DESCRIPTION .\ Add any additional description here .PP -Copy standard input to each FILE, and also to standard output. +Copy standard input to each FILE, and also to standard output. Since there is only one standard out, it can only be piped to one program. However, tee can send output to a file that is a fifo, which can then be read by some other program. .TP \fB\-a\fR, \fB\-\-append\fR append to the given FILEs, do not overwrite @@ -42,3 +42,11 @@ .B info coreutils tee .PP should give you access to the complete manual. +.SH EXAMPLES +cat file1 | sort | tee file1.sorted | uniq file1.uniq +.PP +mkfifo fifo +.br +cat fifo | uniq file1.uniq +.br +cat file1 | sort | tee file.sorted fifo | grep text file1.grep ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: xnanosleep range with 64 bit time_t
On Sun, Aug 27, 2006 at 11:04:23PM -0700, Paul Eggert wrote: Frank v Waveren [EMAIL PROTECTED] writes: I haven't checked how other operating systems handle this (do any others even have 64 bit time_t's?) Yes, pretty much every operating system with 64-bit long has 64-bit time_t, which means most OSes these days (at least on some platform). So we can't install that patch as-is: it would break things on too many platforms. After mailing the above, I went and had a look at a solaris machine. Guess what? 0.0354 getrlimit(RLIMIT_STACK, 0x7448) = 0 0.0355 getcontext(0x7160) 0.0358 context(3, 0x7F0C4EE0) 0.0360 sysconfig(_CONFIG_SEM_VALUE_MAX)= 2147483647 0.0363 nanosleep(0x7AD0, 0x) = 0 0.0366 _exit(4294969536) It does the same thing. 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). That doesn't sound right. Why not just fix nanosleep so that it works instead? It shouldn't be that hard. There shouldn't be an arbitrary upper bound to the length of the sleep. I agree that would be a pleasing solution, but since it'll stop the number of nanoseconds in the sleep from being exressible as a single integer it's going to make a lot of code very unpleasant, and it's certainly no small undertaking. Also, until the kernel bug gets fixed, what's the harm of leaving coreutils alone? The bug occurs only for sleeps longer than about 68 years, so it's not like this is a burning issue. This turns a perfectly reasonable while sleep inf; do done to sleep forever from a slightly unpleasant piece of idiom into a busy wait. I'd say that's worth fixing. -- 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
date -d20060229 gives: invalid date
date Versions 5.96 and 5.97 (at least) have a bug when passing dates that are greater than the actual number of days in a month. Previous versions (most of the machines seem to have 5.2.1) would convert the date to a correct date. For instance date -d20060229 would provide data for March 1. I use this in scripts that I pass a date to as a parameter: let NEXT_DAY=$1+1 NEXT_DATE=`date -d$NEXT_DAY +%Y%m%d` and: let PREV_DAY=$1-1 PREV_DATE=`date -d$PREV_DAY +%Y%m%d` In this case it might do: date -d20060200 which would turn into Jan 31. Maybe this is an undocumented feature that someone thought was a bug. In my case it is very useful . Since this isn't working I figured there must be another way to do this so I started playing around and found: date -d20060228 + 1 day and this does do what I want. However: date -d20060201 - 1 day does not work. It reports Feb 2. Steve -- __ Steve Cousins, Ocean Modeling GroupEmail: [EMAIL PROTECTED] Marine Sciences, 452 Aubert Hall http://rocky.umeoce.maine.edu Univ. of Maine, Orono, ME 04469Phone: (207) 581-4302 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bugs
While working int terminal ,nothing is getting done. Automatically it is displaying some messages after regular short intervals.Please help me if you can . It was mentioned there that i should report bugs to this id. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bugs
While working int terminal ,nothing is getting done. Automatically it is displaying some messages after regular short intervals.Please help me if you can . It was mentioned there that i should report bugs to this id. Unfortunately, this bug report is too vague for anyone else to have a clue how to help you. I suggest reading http://www.catb.org/~esr/faqs/smart-questions.html, searching the web for anyone who might have reported something similar, then trying again with more pertinent information - what OS are you using, what are you trying to get done, what is the actual error message you are seeing (paste it, don't retype it), etc. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested change to tee manpage to show usefulness
0700 +++ tee.1.new 2005-06-06 00:09:16.0 -0700 @@ -8,7 +8,7 @@ .SH DESCRIPTION .\ Add any additional description here .PP -Copy standard input to each FILE, and also to standard output. +Copy standard input to each FILE, and also to standard output. Since there is only one standard out, it can only be piped to one program. However, tee can send output to a file that is a fifo, which can then be read by some other program. Thanks for the attempt. However, the man pages are autogenerated from the --help output and from a tee.x template file, so you would have to rework your patch to hit the upstream source of the manpage. Also, the info pages tend to be more verbose about utilities; check that your patch wouldn't be more appropriate there. And please wrap lines in the patch, rather than letting the mailer wrap them and breaking the patch. I will leave it to Jim, the actual maintainer, whether this patch is worth applying even if these problems are addressed first. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d20060229 gives: invalid date
Steve Cousins [EMAIL PROTECTED] writes: date Versions 5.96 and 5.97 (at least) have a bug when passing dates that are greater than the actual number of days in a month. Previous versions (most of the machines seem to have 5.2.1) would convert the date to a correct date. The change was advertised as a new feature in NEWS: Dates like `January 32' with out-of-range components are now rejected. date -d20060201 - 1 day does not work. It reports Feb 2. Try this: date -u -d2006-02-01 -1 day The -u is to avoid problems with DST transitions. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
