Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sourceware.cygnus.com Delivered-To: mailing list cygwin@sourceware.cygnus.com From: "Kai Henningsen" Organization: Spuentrup CTI To: cygwin@sourceware.cygnus.com, earnie_boyd@yahoo.com Date: Mon, 11 Oct 1999 12:49:22 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: make, bash, or cygwin bug? X-Confirm-Reading-To: "Kai Henningsen" X-pmrqc: 1 In-reply-to: <19991008204107.12010.rocketmail@web110.yahoomail.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id GAA07096 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.) Regards - Kai Henningsen -- http://www.cats.ms Spuentrup CTI Fon: +49 251 322311 0 Windbreede 12 Fax: +49 251 322311 99 D-48157 Münster Mob: +49 161 3223111 Germany GSM: +49 171 7755060 -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com