Re: xnanosleep range with 64 bit time_t

2006-08-28 Thread Paul Eggert
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

determining 64-bit hardware [was: (no subject)]

2006-08-28 Thread Eric Blake
-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

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

2006-08-28 Thread Bruno Haible
+ 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

Re: coreutils-6.0 on BeOS (6)

2006-08-28 Thread Bruno Haible
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

Re: coreutils-6.0 on BeOS (6)

2006-08-28 Thread Simon Josefsson
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?

Re: coreutils-6.1: needs 'ls' patch (bug #15043)

2006-08-28 Thread mwoehlke
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

Re: coreutils-6.0 on BeOS (9)

2006-08-28 Thread Bruno Haible
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

Re: coreutils-6.1: needs 'ls' patch (bug #15043)

2006-08-28 Thread mwoehlke
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

inttypes-related changes for coreutils

2006-08-28 Thread Paul Eggert
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. *

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

2006-08-28 Thread Paul Eggert
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

minor code cleanup from using stat-macros.h

2006-08-28 Thread Paul Eggert
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

Suggested change to tee manpage to show usefulness

2006-08-28 Thread Don Kitchen
--- 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

Re: xnanosleep range with 64 bit time_t

2006-08-28 Thread Frank v Waveren
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

date -d20060229 gives: invalid date

2006-08-28 Thread Steve Cousins
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

bugs

2006-08-28 Thread rahulsin
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

Re: bugs

2006-08-28 Thread Eric Blake
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

Re: Suggested change to tee manpage to show usefulness

2006-08-28 Thread Eric Blake
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

Re: date -d20060229 gives: invalid date

2006-08-28 Thread Paul Eggert
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