Hi,
When started by cron, the following crashes:
* * * * * /bin/date 'Hello %c'
complaining about cannot find endquote
If you try
* * * * * /bin/date 'Hello \%c'
the backslash appears in the output bur forestalls the error.
What is going on please?
Jim Donovan
Office +61+2-8923-5208
Home +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dan Jacobson on 9/28/2006 7:07 AM:
> Fold splits UTF-8 chars into their bytes and probably doesn't know
> about their display width either.
Known issue. Search the archives. Basically, until someone writes an
implementation that makes i
Karl Berry wrote:
> with http://directory.fsf.org/gzip.html; no mention there)... which, of
1.3.5 is mentioned on that Directory page as the "(devel)" release.
Anyway, I wrote rms about the lack of official releases in recent
decades.
Ah, my bad... but then, it's still just "devel" (whic
> with http://directory.fsf.org/gzip.html; no mention there)... which, of
1.3.5 is mentioned on that Directory page as the "(devel)" release.
Anyway, I wrote rms about the lack of official releases in recent
decades.
k
___
Bug-coreutils mailing
The recent change to fail-eperm caused "make check" to fail on my
Debian stable host. I guess its Perl uses a slightly pickier taint
check? I installed the following patch, which fixed the problem.
"man perlsec" suggested adding those three vars.
2006-09-28 Paul Eggert <[EMAIL PROTECTED]>
Since switching coreutils to use gnulib-tool, the lib directory
has had no automatically-generated dependencies.
I finally noticed it today when modifying a lib/*.h header file
and finding that things weren't recompiled.
IMHO, gnulib-tool should leave the default (generate them),
but provide an op
Tim Waugh <[EMAIL PROTECTED]> wrote:
> I discovered that the rm/fail-eperm test can fail if a temporary file
> owned by another user gets selected for attempted deletion when that
> filename contains a space.
Hi Tim,
Thank you for the report and patch.
The problem is actually bigger.
Here's what
Eric Blake <[EMAIL PROTECTED]> wrote:
> xstrtoul is pretty nice! I'll leave it to you to decide how much of coreutils
> is worth extending, but in deference to Jim trying to release, it is worth
> holding off this task until after 6.3 is out.
Thank you :)
___
Paul Eggert CS.UCLA.EDU> writes:
> > POSIX also states that size_t is only guaranteed to be 16 bits.
>
> Really? Where?
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html#tag_13_48
"The following macros specify the minimum and maximum limits of integer types
corresponding t
Eric Blake <[EMAIL PROTECTED]> writes:
> POSIX also states that size_t is only guaranteed to be 16 bits.
Really? Where? Anyway, this is not an issue for coreutils, since the
GNU coding standards say:
However, don't make any effort to cater to the possibility that an
@code{int} will be less
<[EMAIL PROTECTED]> writes:
> http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/7179
> ...
> When building coreutils-5.97 from the long available stable tarball, make
> runs bison and works with Apple's provided versions of the tools.
That's not what that URL says. It says you built from CVS
[EMAIL PROTECTED] wrote:
On 2006-09-27 19:00:44 -0500, mwoehlke <[EMAIL PROTECTED]> said:
Paul Eggert wrote:
<[EMAIL PROTECTED]> writes:
Can I validly talk Apple into upgrading their provided gzip to 1.3.5
when this is not in the stable category (for _whatever_ reason[s])?
If 1.3.5 is fine to
I'm trying to make m4 -l comply with POSIX guidelines for numeric argument
parsing (for example, 'm4 -l a' should issue a complaint that 'a' is not
numeric, although this is silently accepted in M4 1.4.7). I decided to turn to
coreutils for inspiration.
I noticed that various coreutils parse c
Fold splits UTF-8 chars into their bytes and probably doesn't know
about their display width either.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
I didn't have time to reply when I saw this. While I am a long time
ksh/bash user, I know and work with a lot of people who prefer the C
Shell. You are correct in that John can set LC_ALL=C by:
setenv LC_ALL C
On Wed, 27 Sep 2006 09:33:23 -0600
[EMAIL PROTECTED] (Bob Proulx) wrote:
> I see by y
Hi,
I discovered that the rm/fail-eperm test can fail if a temporary file
owned by another user gets selected for attempted deletion when that
filename contains a space.
Here is a simple fix.
Tim.
*/
--- coreutils-5.97/tests/rm/fail-eperm.test 2006-09-28 13:22:34.0 +0100
+++ coreutils-5
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> Is there any type of file system where readdir works?
>
> Yes. It does work on vfat file systems. No readdir bug reproducible there.
Thanks for checking.
>> What version of Darwin are you using?
>
> Darwin 7.9.0 = MacOS X 10.3.9.
>
> I wro
Hello Jim,
> Is there any type of file system where readdir works?
Yes. It does work on vfat file systems. No readdir bug reproducible there.
> What version of Darwin are you using?
Darwin 7.9.0 = MacOS X 10.3.9.
I wrote:
> In the run test, you can use /bin/rm, since /bin/rm has the same bug
>
18 matches
Mail list logo
