coreutils' Makefiles are currently created using
automake-1.9.6 and autoconf-2.59c
There are some very long lines in the Makefiles generated
for upcoming coreutils-5.90. Here's an example:
LIBOBJS = ${LIBOBJDIR}backupfile$U.o ${LIBOBJDIR}basename$U.o ...
The LTLIBOBJS definition had the
Here's the work-around I'm using:
2005-09-29 Jim Meyering [EMAIL PROTECTED]
* settime.c (settime): Move the HAVE_STIME block `up' into an #elif
block, so that we don't even try to compile it if settimeofday is
available. This works around a compilation failure on OSF1
Jim Meyering wrote:
I've added this:
stat now exits nonzero if a file operand does not exist
Very good!
Thanks
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Hello Paul, Bob and others listening,
· even though the C compiler might be able to deal with 64-bit integer
values,
this must *not* be the case with the C pre-processor:
#define ULLONG_MAX 18446744073709551615ULL
the C compiler (gcc v2.7.2.1) *is* able to deal with that
ThMO [EMAIL PROTECTED] writes:
the header file xtime.h defines:
# if HAVE_LONG_LONG
typedef long long int xtime_t;
# define XTIME_PRECISION 10LL
# else
...
#endif
Again cpp groks about the `LL' modifier.
Thanks for catching that portability problem to GCC 2.7.2.1.
ThMO [EMAIL PROTECTED] writes:
The neccessary parameter is: --info-page=coreutils $*
That way the man-page clearly state the command to type as:
info coreutils cmd
without the need to name each command inside the info/dir file explicitely.
Thanks for the suggestion. So, I take it that
Jim Meyering [EMAIL PROTECTED] writes:
+#elif HAVE_STIME
+ {
+/* This fails to compile on OSF1 V5.1, due to stime requiring
+ a `long int*' and tv_sec is `int'. But that system does provide
+ settimeofday. */
+int r = stime (ts-tv_sec);
+if (r == 0 || errno ==
Paul Eggert [EMAIL PROTECTED] wrote:
That can't work, as it has unbalanced {. Also, it's probably better
Thanks for catching that.
BTW, do you know what (if any) system ends up using that HAVE_STIME block?
I did run test builds on lots of systems, and none failed.
just to return whatever
Paul Eggert [EMAIL PROTECTED] wrote:
ThMO [EMAIL PROTECTED] writes:
The neccessary parameter is: --info-page=coreutils $*
That way the man-page clearly state the command to type as:
info coreutils cmd
without the need to name each command inside the info/dir file explicitely.
Thanks for
Hello Paul,
the header file xtime.h defines:
# if HAVE_LONG_LONG
typedef long long int xtime_t;
# define XTIME_PRECISION 10LL
# else
...
#endif
Again cpp groks about the `LL' modifier.
Thanks for catching that portability problem to GCC 2.7.2.1. Please
Hello Jim, Paul and others listening,
[...]
Jim, what do you think?
We've been around the block a few times with Debian,
trying to do just that, but there's at least one problem:
`info coreutils pr' would display the `printing text'
section of the manual, not the one on `pr
Hello Paul and others listening,
The neccessary parameter is: --info-page=coreutils $*
That way the man-page clearly state the command to type as:
info coreutils cmd
without the need to name each command inside the info/dir file explicitely.
Thanks for the suggestion. So, I take it
I'm pondering about implementing pkill like functionality in kill,
instead of introducing a new command specific for the purpose. My
idea is basicly to make `kill' accept a name instead of just a pid, so
the command would look something like:
kill [-s SIG | -SIGNAL] PID | NAME
Personally, I
ThMO [EMAIL PROTECTED] writes:
· lib/getdate.y:
I'm using bison v1.28 - and for me it's unacceptable, that this grammar
can't be processed corrrectly with this older version,
You shouldn't need to process it at all, since getdate.c is present in
the source distribution. Perhaps the
Alfred M\. Szmidt [EMAIL PROTECTED] writes:
kill [-s SIG | -SIGNAL] PID | NAME
Personally, I think this makes more sense than introducing pkill (or
for that matter, killall). And is cleaner. What do people think
about this?
Most people use the builtin kill command of the shell, so you'll
Jim Meyering [EMAIL PROTECTED] writes:
[OSF1] does have options to switch between 32 and 64-bit modes,
but I didn't think it'd be worthwhile, for code that might
never be used.
Yes, but I'm more worried about date, ls, etc. These all use time_t,
and if OSF1 can be cajoled into using 64-bit
ThMO [EMAIL PROTECTED] writes:
I do have a shorter patch for you:
...
-# define XTIME_PRECISION 10LL
+# define XTIME_PRECISION 10L
Thanks, but if XTIME_PRECISION can't be of the correct type, I'd
rather just make it 'int' on all platforms and be done with it.
With both
Most people use the builtin kill command of the shell, so you'll
have to change Bash as well as coreutils.
I wish that bash would remove all those builtins, or only use them if
a such a builtin doesn't exist on the system.
bash has the enable builtin which lets you disable builtins:
Remember, POSIX requires kill(1) to be a shell builtin, because it
must support job syntax (kill %1, for example), which cannot be
done with normal POSIX child process semantics.
In that case, one can make the builtin kill a wrapper, that parses the
command line, and if it see %1 it
[EMAIL PROTECTED] (Eric Blake) writes:
Remember, POSIX requires kill(1) to be a shell builtin, because it
must support job syntax (kill %1, for example), which cannot be
done with normal POSIX child process semantics.
In that case, one can make the builtin kill a wrapper, that
Write your own shell function that does just that.
Nice, but I'd rather have it default in bash. Might just patch that
horrid beast...
True. But in this case, it doesn't make it wrong, either. Another
argument for making kill a builtin is if you hit your ulimit on max
processes,
There have been many changes since the last release (unstable 5.3.0).
So many that I feel 5.90 should also be considered unstable, at least
initially.
Minor nit during compilation on cygwin:
make[3]: Entering directory `/home/eblake/coreutils-5.90/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I..
[EMAIL PROTECTED] (Eric Blake) writes:
dd.c:1661: warning: long unsigned int format, size_t arg (arg 5)
Thanks; I installed this patch.
Jim -- I'm not sure what version number you want at the top of
ChangeLog so I left it out for now.
2005-09-29 Paul Eggert [EMAIL PROTECTED]
*
23 matches
Mail list logo
