Hi,
On Sun, 7 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
however:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or
Martin Koeppe wrote:
I just found the bug in gettext causing this trouble. Unfortunately I
didn't find a gettext mailing list.
For most GNU programs, you find the bug reporting address at the end of
the program --help output. gettext --help is in this category.
Gettext is 0.16.1, file
Hi Bruno,
On Sun, 14 Oct 2007, Bruno Haible wrote:
Martin Koeppe wrote:
I just found the bug in gettext causing this trouble. Unfortunately I
didn't find a gettext mailing list.
For most GNU programs, you find the bug reporting address at the end of
the program --help output. gettext
Martin Koeppe wrote:
Thanks. Unfortunately, this
http://lists.gnu.org/archive/html/bug-gnu-gettext/
is not a valid URL (404). And I looked on
http://lists.gnu.org/archive/html/
for gettext or intl and couldn't find either.
The bug-gnu-gettext archives are at
sorry, just noted that I forgot to add the list in reply...
-- Forwarded message --
Date: Tue, 9 Oct 2007 09:49:29 +0200 (CEST)
From: Martin Koeppe
To: Bruno Haible
Subject: Re: Fwd: Re: error.c: Unknown system error should report errno value
On Tue, 9 Oct 2007, Bruno Haible
Martin Koeppe wrote:
The relevant output is done by asprintf(). And by printf() in line 269.
That's it. coreutils needs to use also printf-posix, not only vasprintf-posix.
Then 'seq' should work.
Bruno
___
Bug-coreutils mailing list
On Sat, 13 Oct 2007, Bruno Haible wrote:
Martin Koeppe wrote:
The relevant output is done by asprintf(). And by printf() in line 269.
That's it. coreutils needs to use also printf-posix, not only vasprintf-posix.
Then 'seq' should work.
Or modify seq to not use printf() so that not every
Hi Jim, hi Bruno,
On Sat, 6 Oct 2007, Jim Meyering wrote:
Bruno Haible [EMAIL PROTECTED] wrote:
Martin Koeppe wrote:
The Interix libc is built with MSVC. MSVC has no long double data
type. Ok, it understands long double, but always maps that to 64-bit
double. So libc's printf(), when it
Martin Koeppe wrote:
Is seq segfaulting on mingw and BeOS, too?
I just tested snapshot 316 and it unfortunately doesn't work on
Interix, i.e. seq is still wrong.
Can you find out why?
Interix has _ before C symbols, all the following are asm symbols. The
Interix libc has __vfprintf
Hi Bruno,
On Tue, 9 Oct 2007, Bruno Haible wrote:
Martin Koeppe wrote:
Is seq segfaulting on mingw and BeOS, too?
I just tested snapshot 316 and it unfortunately doesn't work on
Interix, i.e. seq is still wrong.
Can you find out why?
Now found out, that GNULIB_SPRINTF_POSIX and
Martin Koeppe wrote:
Now found out, that GNULIB_SPRINTF_POSIX and REPLACE_SPRINTF are set
to 0 by configure, seems to be the default value, and apparently
nowhere else get touched during configure (I only see 2 occurences of
these 2 variables in the whole configure), so stay 0 and
On Sat, 6 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
The first 'Segmentation fault' with dd doesn't occur when I run just
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync dd-in dd-out
dd-out looks fine there. So I don't currently know how to
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or diectory
remove.c:1094 reads like this:
error (0, errno, _(cannot remove %s),
quote (full_filename (filename)));
_() and
On Sun, 7 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
The test tests/rm/dir-nonrecur shows IMO a real bug in coreutils,
however:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or
Bruno Haible [EMAIL PROTECTED] wrote:
rm d should fail at
remove.c:1094 with cannot remove 'd': Is a directory
but fails there with cannot remove 'd': No such file or diectory
remove.c:1094 reads like this:
error (0, errno, _(cannot remove %s),
quote
Martin Koeppe [EMAIL PROTECTED] wrote:
The first 'Segmentation fault' with dd doesn't occur when I run just
the failing command in the src dir:
./dd cbs=4 ibs=4 conv=unblock,sync dd-in dd-out
dd-out looks fine there. So I don't currently know how to reproduce
it...
How about when you run
Martin Koeppe wrote:
The Interix libc is built with MSVC. MSVC has no long double data
type. Ok, it understands long double, but always maps that to 64-bit
double. So libc's printf(), when it sees %Lg, expects 64-bit double.
But Interix also has gcc. gcc OTOH has 80 bit long double (stored
Bruno Haible [EMAIL PROTECTED] wrote:
Martin Koeppe wrote:
The Interix libc is built with MSVC. MSVC has no long double data
type. Ok, it understands long double, but always maps that to 64-bit
double. So libc's printf(), when it sees %Lg, expects 64-bit double.
But Interix also has gcc.
Jim Meyering wrote:
Is seq segfaulting on mingw and BeOS, too?
On BeOS, 'seq' is producing junk output (totally out-of-range numbers) but
not segfaulting. As a consequence, the rm/readdir-bug test fails.
On mingw, I don't remember the details, but it was similar.
Bruno
Hi Jim,
On Wed, 3 Oct 2007, Jim Meyering wrote:
And yes, I'll of course try a new coreutils/gnulib version (but I
think in this case I shouldn't yet). Are there any coreutils snapshot
.tar.gz available?
Yes. I made a new snapshot just a few hours ago, too:
Martin Koeppe [EMAIL PROTECTED] writes:
The Interix libc is built with MSVC. MSVC has no long double data
type. Ok, it understands long double, but always maps that to 64-bit
double. So libc's printf(), when it sees %Lg, expects 64-bit double.
But Interix also has gcc. gcc OTOH has 80 bit
On Thu, 27 Sep 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
...
And yes, I'll of course try a new coreutils/gnulib version (but I
think in this case I shouldn't yet). Are there any coreutils snapshot
.tar.gz available?
Yes. I made a new snapshot just a few hours ago,
Martin Koeppe [EMAIL PROTECTED] wrote:
On Thu, 27 Sep 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
...
And yes, I'll of course try a new coreutils/gnulib version (but I
think in this case I shouldn't yet). Are there any coreutils snapshot
.tar.gz available?
Yes. I
Martin Koeppe [EMAIL PROTECTED] wrote:
A question arises: How should one portably test for root? Neither
root nor uid 0 seem to be a POSIX requirement. I found one solution
so far, but I'm not sure how good it really is:
For shell scripts run:
$ /usr/sbin/chroot / /bin/true
If successful,
On Wed, 3 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
A question arises: How should one portably test for root? Neither
root nor uid 0 seem to be a POSIX requirement. I found one solution
so far, but I'm not sure how good it really is:
For shell scripts run:
$
John Cowan [EMAIL PROTECTED] wrote:
Jim Meyering scripsit:
What if chroot works for non-privileged users on some type of system?
That sounds extremely unlikely, [...]
It's not so far-fetched.
There's a hint on the first lines of info coreutils chroot:
`chroot' runs a command with a
Martin Koeppe [EMAIL PROTECTED] wrote:
On Wed, 3 Oct 2007, Jim Meyering wrote:
Martin Koeppe [EMAIL PROTECTED] wrote:
A question arises: How should one portably test for root? Neither
root nor uid 0 seem to be a POSIX requirement. I found one solution
so far, but I'm not sure how good it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/3/2007 8:26 AM:
I'm leery of this.
What if chroot works for non-privileged users on some type of system?
It works for all users on cygwin (seeing as how chroot isn't natively
provided by Windows, cygwin has no
28 matches
Mail list logo
