> Can we easily get cat>foo (or some equivalent) to produce CRLF files?
I guess I meant, "can we get cat>foo (or some equivalent)" to produce
CRLF files *when hello does*. That is, to get some standard command to
operate in text mode under mingw[/cygwin/whatever]. Does echo also
operate in b
Bruno Haible <[EMAIL PROTECTED]> writes:
> Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
>
> stat.c: In function `print_statfs':
> stat.c:416: error: incompatible types in initialization
Thanks for reporting this. Oops, this is another MacOS problem (I got
misled by
I saw the fdl module, which is nice because my GNU project GMediaServer uses
fdl.texi in its documentation. It however also uses gpl.texi, which is why I
propose this module.
2006-08-29 Oskar Liljeblad <[EMAIL PROTECTED]>
* modules/gpl: New module, for grabbing gpl.texi
* MODULE
Bruno Haible <[EMAIL PROTECTED]> writes:
> Single-stepping with "next" yields a loop in tail.c:
This is because 'tail' is confused again about the distinction between
pipes and sockets. This is a bit of a can of worms (it was the topic
of a discussion on the Open Group a while ago, so I knew abo
Eric Blake <[EMAIL PROTECTED]> writes:
> I was interested in trying out the new config-h module. But it only
> works when using gnulib-tool --import/--update; the sed expression
> is not applied for files copied manually using --extract*
> information.
That sounds like a bug, both for the gettex
Hello Karl,
* Karl Berry wrote on Mon, Aug 28, 2006 at 08:31:37PM CEST:
> > However, on MinGW all three tests fail because the program outputs CRLF
> > line endings, while the test suite creates files with LF ending.
>
> Um, why? That is, why does cat>foo produce LF files while hello>foo
Bruno Haible clisp.org> writes:
>
> While doing the coreutils changes, Paul found the answer to the long-standing
> question how gnulib-tool could be used without requiring a lib/ directory of
> its own and while still maintaining a clear separation between hand-maintained
> files and autogenera
Hello Jim,
* Jim Meyering wrote on Tue, Aug 29, 2006 at 06:55:19PM CEST:
>
> Even if there is a tiny efficiency gain (I don't see it),
> such a change would feel like obfuscation.
Never mind, I was hallucinating again.
Sorry 'bout that,
Ralf
Eric Blake byu.net> writes:
> > > Meanwhile, is this patch acceptable, which updates the _LIBC
> > > portions of the error module to resemble CVS glibc more closely, so
> > > that I have fewer spurious diffs to filter through?
> >
> > Yes, and thanks for doing some of this (normally-thankless) t
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
> * Jim Meyering wrote on Tue, Aug 29, 2006 at 05:52:02PM CEST:
>>
>> Here's one more little change I've applied. Without it, rerunning
>> coreutils' bootstrap and building would not update a stale copy of
>> configmake.h, containing the no
Ralf Wildenhues wrote:
> > > Question to the autoconf experts: Is it possible to write a macro
> > > AM_GETTEXT_NEED_NGETTEXT such that whenever a user writes
> > >AM_GETTEXT_NEED_NGETTEXT
> > >AM_GNU_GETTEXT
> > > or
> > >AM_GNU_GETTEXT
> > >AM_GETTEXT_NEED_NGETTEXT
> > > the AM_GN
Hello Jim,
* Jim Meyering wrote on Tue, Aug 29, 2006 at 05:52:02PM CEST:
>
> Here's one more little change I've applied. Without it, rerunning
> coreutils' bootstrap and building would not update a stale copy of
> configmake.h, containing the now-invalid CONFIGMAKE_ prefixes.
> -configmake.h:
>
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for your suggestions, which were all right on the money.
> I installed the following patch, which incorporates them.
>
> 2006-08-29 Paul Eggert <[EMAIL PROTECTED]>
>
> * modules/configmake (Makefile.am): Add a comment, and omit
> the CON
> + echo '#define LIBDIR "$(libdir)"'; \
Thanks. I now did this change.
2006-08-29 Bruno Haible <[EMAIL PROTECTED]>
* modules/localcharset (Depends-on): Add configmake.
(Makefile.am): Remove setting of LIBDIR through DEFS.
* lib/localcharset.c: Include configmake.
* Paul Eggert wrote on Tue, Aug 29, 2006 at 04:34:01PM CEST:
> Bruno Haible <[EMAIL PROTECTED]> writes:
> >
> > Question to the autoconf experts: Is it possible to write a macro
> > AM_GETTEXT_NEED_NGETTEXT such that whenever a user writes
> >AM_GETTEXT_NEED_NGETTEXT
> >AM_GNU_GETTEXT
> > o
Bruno Haible <[EMAIL PROTECTED]> writes:
>>glibc2.m4 intdiv0.m4 inttypes-h.m4 inttypes-pri.m4 lcmessage.m4
>>lock.m4 printf-posix.m4 size_max.m4 uintmax_t.m4 ulonglong.m4
>>visibility.m4 xsize.m4
>
> Assuming aclocal-1.9 or newer, I think we could remove these files
> from the modules/
Thanks for your suggestions, which were all right on the money.
I installed the following patch, which incorporates them.
2006-08-29 Paul Eggert <[EMAIL PROTECTED]>
* modules/configmake (Makefile.am): Add a comment, and omit
the CONFIGMAKE_ prefix from generated macro names. Su
Paul Eggert wrote:
> what is the
> recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool,
> and autopoint/autoreconf in such a way that you don't get the
> following files into your m4 directory afterwards?
>
>glibc2.m4 intdiv0.m4 inttypes-h.m4 inttypes-pri.m4 lcmessage.m4
>l
Paul Eggert wrote:
> It seems a bit cleaner to me to have
> the inttypes module be the only module that needs to figure out
> the absolute name of .
Maybe a bit cleaner, but also a little more complex... But I don't mind.
Both codes look equally safe.
Bruno
Paul Eggert wrote:
> Bootstrapping coreutils found one minor glitch: inttypes now relies on
> gl_HEADER_INTTYPES_H indirectly via gt_INTTYPES_PRI but doesn't list
> the file containing it.
Thanks for noticing it! It was certainly not intended. I'll clean it up.
> While we're on the subject we sho
Paul Eggert wrote:
> 2006-08-25 Paul Eggert <[EMAIL PROTECTED]>
>
> New configmake module, so that "make" output needn't be cluttered
> by fluff like '-DLIBDIR=\"/usr/local/lib\"'.
> * modules/configmake: New file.
IMO it would be useful to add comments that tell:
- Why does
21 matches
Mail list logo
