B20.1: CR-LF translation not always handled properly

["Jon Leichter" <jon at symas dot com>]

I have read through your FAQs and searched your mailing list, and I not have
been able to find information about the problem that I am reporting:

Rather than use the Mingw32 support in the version of 'gcc' supplied with
Cygwin, I decided to download and install gcc-2.95-mingw32.zip on my system. I
had chosen this option because I wanted the most up to date Mingw32 system,
and I didn't want to have to apply the various patches to the 'gcc' system
installed with Cygwin. To make sure that I ended up using Mingw32 compiler
tools, I made sure that its 'bin' directory preceded Cygwin's 'bin' directory
in my PATH.

Early on, I noticed that various tools from the standalone Mingw32 package
generates the CR-LF pair in its output. (Cygwin's tools do not). This should
be ok, because Cygwin's environment is supposed to account for this
possibility. However, this is not always the case. The following are two
examples where I had problems:

- I found a problem with bash's command substitution. Using the standalone
Mingw32 package, one could do the following:

	$ xx=`gcc -pring-prog-name=ld`

The value of xx ends up being "ld^M". If I then use this variable with various
shell commands, I do not get the correct results. For instance the following
would evaluate to false (if ld was in the current directory):

	$ test -f ./$xx

Thus, it seems as though command substitution in bash is broken. It should be
filtering the output of commands for the potential need to do a CR-LF
translation. (Note that Cygwin's version of 'gcc' does not generate the CR
character in its output, so this problem does not surface).

I found this problem when running a 'configure' script. 'configure' was unable
to verify that I had an 'ld' binary on my system as a result.

- Another command that is likely to be broken is Cygwin's 'sed' command. I
found this out, as well, while running a 'configure' script. 'sed' fails to
parse the output from Mingw32's 'nm' command because the 'nm' command
generates CR-LF pairs in its output.

As an example, if you wanted to translate all of the external symbol output of
'nm' into symbol names only, one might try:

	$ nm -g xx.o | sed -e 's/[0-9a-z]* [ABCDGISTW] \([_A-Za-z0-9]*\)$/\1/'

Because the output of Mingw32's 'nm' generates ^M characters at the end, the
above command fails. The key to this failure is that prior to '$', the only
permitted characters are [_A-Za-z0-9], which does NOT include the ^M
character.

As a result of this problem, the 'configure' script that I was running was
unable to successfully interpret 'nm' output.

---

Basically, a bunch of Cygwin's tools are probably broken. Note that not all
tools should be adjusted. For instance, 'od' does the correct thing (using
stdin in binary mode). If this were not the case, I might not had tracked down
the problem.

I also noticed that the 'grep' command seems to do the 'right' thing. If I
pipe output through grep, it translates CR-LF pairs into LF.

One might argue that the problem is with Mingw32's standalone package, that
its tools should not be generating the CR-LF pair in its output. But, this
does not seem reasonable, since these tools are expected to run in the DOS
environment as well.

Like I said, I suspect that there are more 'broken' tools, but I have not had
the time to chase them down. In order for me to do my work, I had to abandon
using the standalone Mingw32 package in Cygwin, and I now, instead, use
Cygwin's built-in support for Mingw32 (with update patches applied).


System Information
------------------
Pentium II 400 MHz
128 MB RAM
Windows NT Server 4.0
Cygwin B20.1
Mingw32 gcc 2.95


Jon Leichter
jon@symas.com


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