Mail Archives: cygwin/1999/10/22/07:36:52
I've gotten a few responses to my original email (that I've included at the
end) about this problem. None of the suggestions have changed the behavior.
Now, I'd like to suggest how to reproduce the problem:
- Install a fresh, clean installation of Cygwin B20.1.
- Do as little configuration as possible. Allow the default configuration to
remain. Thus, the root (/) ought to be mounted on top of C: in textmode
(text!=binary). Also, create the /tmp directory, like you're supposed to.
- Now, download the latest standalone Mingw32 package:
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95/
Download the gcc-2.95-mingw32.zip file.
- Install gcc-2.95-mingw32.zip somewhere under the root file system hiearchy.
This should imply that all tools will be ran in textmode by default.
- Once installed, make sure that Mingw32's 'bin' directory precedes Cygwin's
'bin' directory in your PATH. This is significant to assure that Mingw32 tools
are ran instead of Cygwin tools.
- 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.
Now, try this:
$ echo $xx | cat | od -x
Notice no change.
Now try this:
$ echo $xx | grep ".*" | od -x
Notice that the ^M has (correctly) been stripped.
Not only should 'cat' have done the right thing, but the orignal command
substitution should never have ended up with the ^M character.
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.
Someone please try these tests and let me know if you see the same behavior
that I have described.
Jon Leichter
jon AT symas DOT com
> -----Original Message-----
> From: Jon Leichter [mailto:jon AT symas DOT com]
> Sent: Thursday, October 21, 1999 4:16 PM
> To: cygwin AT sourceware DOT cygnus DOT com
> Cc: jon AT symas DOT com
> Subject: B20.1: CR-LF translation not always handled properly
>
>
> 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 AT symas DOT com
>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -