This is the mail archive of the
mailing list for the Cygwin project.
RE: make, bash, or cygwin bug?
- To: "'Kai Henningsen'" <kai at cats dot ms>, cygwin at sourceware dot cygnus dot com, earnie_boyd at yahoo dot com
- Subject: RE: make, bash, or cygwin bug?
- From: Bernard Dautrevaux <DAUTREVAUX at microprocess dot com>
- Date: Tue, 12 Oct 1999 16:02:45 +0200
> -----Original Message-----
> From: Kai Henningsen [mailto:email@example.com]
> Sent: Monday, October 11, 1999 12:49 PM
> To: firstname.lastname@example.org; email@example.com
> Subject: Re: make, bash, or cygwin bug?
> On 8 Oct 99, at 13:41, Earnie Boyd wrote:
> > --- Glenn Spell <firstname.lastname@example.org> wrote:
> > > On 8 Oct 1999 around 10:12AM (+0200) Kai Henningsen wrote:
> > >
> > > > /bin/sh: \home\gcc-2.95.1\kai\gcc\cc1obj.exe^M: command not
> > > > found
> > > >
> > > > Well, of course. But who told you to append a cr there?
> > > >
> > > > This Makefile line:
> > > >
> > > > CC1OBJ = `$(CC) -print-prog-name=cc1obj`
> > >
> > > I suspect this is (again) a symptom of mixing mingw and cygwin.
> > > The cygwin port of gcc-2.95 does not append the cr.
> > >
> > > If you could figure out how to get 'cygpath' to print the
> > > output instead of mingw-gcc, it would probably work. :-)
> > Or, try SET CYGWIN=... nobinmode ... before starting bash.
> The [no]binmode
> > switch controls the processing of the pipe and redirect
> fd's. If you modify
> > this value after you start bash you effect the change only
> on pipes not redirects.
> I happen to think this is the wrong type of fix. It's not piping in
> general that should be done in text mode (because there can
> certainly be binary data sent around in pipes - say, the pbm tools),
> but parsing stuff like `` or $(shell ...) (where we _know_ we're
> handling text).
> Typically, these places already have some way to handle '\n' so as
> to make it work as white space. Under cygwin, this should
> probably be extended to '\r'. (This way may well be that later
> parsing routines handle '\n' like white space, not the place that
> takes the output from a program. OTOH, I can see no reason why
> parsing text should ever need to handle '\r' as something different
> from white space, so doing this change should not result in
I've implemented this in my own programs: the pipes are by default opened
binary-mode on the write side and text-mode on the read side, then a program
that needs to read binary data open its read side explicitely binary-mode.
This way we get rid of the superfluous \r in all programs that are not
prepared to cope with binary data; and if I read this way pure binary data
in such a program, I miss the \r's but anyway I will not understand what I
read, so there is no harm :-(.
Always opening the write side binary-mode will further simplify the problem:
even someone forgot to open the read side text-mode, if I write text, he
gets properly parsed text lines :-)
I remember this subject already was debated on the list some months ago, but
obviously with no satisfactory solution, as the problem is still there :-(
97 bis, rue de Colombes
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
Want to unsubscribe from this list?
Send a message to email@example.com