> Date: Mon, 9 Apr 2007 18:55:50 -0500
> From: [EMAIL PROTECTED] (Karl Berry)
> Cc: bug-gnulib@gnu.org, bug-texinfo@gnu.org
>
> eliz> I only saw [non-hierarchy] in one manual
>
> What was the manual?
info.texi, of course.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/9/2007 11:51 AM:
> Eric Blake <[EMAIL PROTECTED]> writes:
>
>> +#elif HAVE___FPURGE
>> + /* __fpurge has no return value, so we must check errno. */
>> + errno = 0;
>> + __fpurge (stream);
>> + if (errno)
>> +res
> POSIX prohibits the use of NUL in Awk input
> files, so portable scripts can't assume it.
Sure, but in the particular case of bootstrapping gnu packages, if gawk
works, that seems pretty sufficient to me? I don't see why we need to
cater for other implementations in *GNU* libtool. It's not lik
On Mon, Apr 09, 2007 at 06:55:50PM -0500, Karl Berry wrote:
> removing the prev/next/up pointers from all other chapters and
> top-level nodes in the findutils manual
>
> Just to chime, I too say to remove 'em, from findutils and everywhere
> else. Down with node pointers!
>
> eliz>
removing the prev/next/up pointers from all other chapters and
top-level nodes in the findutils manual
Just to chime, I too say to remove 'em, from findutils and everywhere
else. Down with node pointers!
eliz> I only saw [non-hierarchy] in one manual
What was the manual?
Happy edit
> From: Paul Eggert <[EMAIL PROTECTED]>
> Date: Mon, 09 Apr 2007 10:19:25 -0700
> Cc: bug-gnulib , bug-texinfo@gnu.org
>
> I agree with Eric: the most elegant way is to do what almost every
> other GNU package has done, namely, to remove those redundant pointers
> from the .texi file.
Agreed. In
Eric Blake <[EMAIL PROTECTED]> writes:
> +#elif HAVE___FPURGE
> + /* __fpurge has no return value, so we must check errno. */
> + errno = 0;
> + __fpurge (stream);
> + if (errno)
> +result = EOF;
> + else
> +{
> + result = 0;
> + errno = e1;
> +}
This doesn't look righ
"James Youngman" <[EMAIL PROTECTED]> writes:
> My guess is that I could work around this problem by removing the
> prev/next/up pointers from all other chapters and top-level nodes in
> the findutils manual. That seems a bit extreme though. Is there a
> more elegant way to solve this problem?
Bruno Haible <[EMAIL PROTECTED]> writes:
> Globally, I think this is backwards: 'copysign' is a more general function
> than 'signbit',
That's true in general but this is a special case. 'copysign' has
been standardized since 1985, is well understood, and is available on
many older platforms. '
[EMAIL PROTECTED] (Karl Berry) writes:
> what is the issue with awk and NUL bytes? Does gawk really
> eat NULs? Or is it other awks that are the problem? Or is the problem
> theoretical?
Old versions of Gawk mishandle NUL in some cases, though I don't know
of any bugs in the latest stable vers
[EMAIL PROTECTED] (Karl Berry) writes:
> Is there any modern (or even not-so-modern) system that does not provide
> fold and cut?
It's not just a question of whether it provides fold and cut. It's a
question of whether it provides versions that are reliable enough for
our purposes (which include
Bruno Haible clisp.org> writes:
>
> On FreeBSD 6.1, printf of "%010a" of Infinity and NaN yields
> "000inf" and "000nan", respectively.
>
> While on glibc systems, it yields
> " inf" and " nan", respectively.
>
> I find glibc's output more sensible, since strtod will accept
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to James Youngman on 4/9/2007 5:33 AM:
>
> My guess is that I could work around this problem by removing the
> prev/next/up pointers from all other chapters and top-level nodes in
> the findutils manual. That seems a bit extreme though.
B
Hello all,
GNU findutils currently uses the full @node command for speficying the
navigational structure of the Findutils manual. So it contains @node
commands like this:-
@menu
* Introduction::Summary of the tasks this manual describes.
* Finding Files:: Finding
14 matches
Mail list logo
