This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: make, bash, or cygwin bug?


> -----Original Message-----
> From: Kai Henningsen [mailto:kai@cats.ms]
> Sent: Monday, October 11, 1999 12:49 PM
> To: cygwin@sourceware.cygnus.com; earnie_boyd@yahoo.com
> Subject: Re: make, bash, or cygwin bug?
> 
> 
> On 8 Oct 99, at 13:41, Earnie Boyd wrote:
> 
> > --- Glenn Spell <glenn@gs.fay.nc.us> 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 
> problems.)
> 

Right. 

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 :-(

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]