Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-ID: <3AC9A1611DF4D211AA8E00105AA56D8A049443@iis000.microdata.fr> From: Bernard Dautrevaux To: "'Kai Henningsen'" , cygwin AT sourceware DOT cygnus DOT com, earnie_boyd AT yahoo DOT com Subject: RE: make, bash, or cygwin bug? Date: Tue, 12 Oct 1999 16:02:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id KAA03824 > -----Original Message----- > From: Kai Henningsen [mailto:kai AT cats DOT ms] > Sent: Monday, October 11, 1999 12:49 PM > To: cygwin AT sourceware DOT cygnus DOT com; earnie_boyd AT yahoo DOT com > Subject: Re: make, bash, or cygwin bug? > > > On 8 Oct 99, at 13:41, Earnie Boyd wrote: > > > --- Glenn Spell 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 AT microprocess DOT com b DOT dautrevaux AT usa DOT net -------------------------------------------- -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com