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: <3AC9A1611DF4D211AA8E00105AA56D8A049450@iis000.microdata.fr> From: Bernard Dautrevaux To: "'Jon Leichter'" , cygwin AT sourceware DOT cygnus DOT com Subject: RE: B20.1: CR-LF translation not always handled properly Date: Fri, 22 Oct 1999 21:08:41 +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 PAA26079 > -----Original Message----- > From: Jon Leichter [mailto:jon AT symas DOT com] > Sent: Friday, October 22, 1999 1:34 PM > To: cygwin AT sourceware DOT cygnus DOT com > Subject: RE: B20.1: CR-LF translation not always handled properly > > > - At the command prompt, type the following: > > $ xx=`gcc -print-prog-name=ld` > $ echo $xx | od -x > > This step ought to clearly show (by looking at the hex dump) > that the xx > variable has been set to the value "ld^M", which is completely wrong. I agree, `` should read in text mode > > Now, try this: > > $ echo $xx | cat | od -x > > Notice no change. This is correct. By definition 'cat' was expected to correctly handle binary data, so it _must_ read the pipe in binary mode. No problem here; it's execatly what it should be. > > Now try this: > > $ echo $xx | grep ".*" | od -x > > Notice that the ^M has (correctly) been stripped. This is correct also; grep is handling textual data, so correctly set its input pipe to read in text mode. > > Not only should 'cat' have done the right thing, but the > orignal command > substitution should never have ended up with the ^M character. 'cat' is ok, but bash (or ash, depending on what you use as /bin/sh) _must_ use text mode when reading the pipe used for command substitution. This thread was already followed seevral times. I don't think theer is a problem here with cygwin1.dll :-), but rather with bash/ash command substitution ;-<. > > The Mingw32 tools produce ^M characters in its output, and there isn't > anything that can be done about that. It is the > responsibility of the Cygwin > tools (especially the ones that process text) to make sure > that stdin and > stdout have been opened in textmode, and this simply does not > seem to be > happening with all of the tools. And this is not only the case of mingw32. Using a Windows box mean we are interested in accessing Windows resources. You'll get the same problems if some Windows application generate a list of items and I try to handle it by: for i in `cat windows-generated-file.txt`; do etc... 'cat' is correct in handling 'windows-generated-file.txt' in binary mode as he has no way to know its text; but the shell _knows_ it's text so it must read it as text. > > Someone please try these tests and let me know if you see the > same behavior > that I have described. I've seen this regularly and have found no other solution as filtering through some '^M'-suppressing program (although I've not think at grep for this purpose). Hope this helps clarify what the problem is; I think cygwin1.dll is OK, but 'sh' is not. 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