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
http://lists.gnu.org/ar
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 " --help" output. "gettext --help" is
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 " --help" output. "gettext --help" is in this category.
> Gettext is 0.16.1, file dcigett
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 f
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 c
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
Bug-coreutils@g
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 2
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 sprint
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 REPLACE_S
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 __vfprin
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
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"),
>
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
> > "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)));
_
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 diectory"
>
> If I remove the tra
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 t
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
_
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
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
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 y
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
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:
http://meyering.net/cu/coreutils
-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 ab
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 s
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
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:
$ /u
Jim Meyering scripsit:
> What if chroot works for non-privileged users on some type of system?
That sounds extremely unlikely, as it is a great big security hole.
With such a chroot, an unprivileged process could put a fake root around
a setuid program, supplying it with a forged /etc/passwd and
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 s
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 avail
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, t
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, too:
http://meyering.net/cu/coreutils-6
Hi Eric,
On Tue, 25 Sep 2007, Eric Blake wrote:
Martin, [offlist]
I don't know if you saw this when the discussion migrated to gnulib, but
I didn't, thank you.
rather than patching error.c, I went with the option of fixing Interix's
non-POSIX strerror instead (C99 and POSIX require strerr
32 matches
Mail list logo
