Mail Archives: cygwin/1999/10/22/01:08:58
I've tried your suggestions. Setting CYGWIN to nobinmode had no effect.
The way I see it, the fact that pipes and redirection default to binmode is
irrelevant. The important thing is that a program like 'sed' should first be
doing a setmode to text mode on stdin (and stdout for that matter). It does
not appear to be doing this, otherwise I would not be seeing this problem.
'grep', on the other hand, must be doing exactly this, otherwise I'd see ^M
characters in its output, but I don't.
I've written my own test program to verify this. Stdin is in binmode by
default. If I change it to textmode, translationn works.
Like I said, I don't know the complete set of tools that are 'broken'. I only
know that 'sed' and command substitution in 'bash' appear to be broken. There
may be others.
I, too, can mix Mingw32 and Cygwin, and I can build binaries and so forth. The
real problems occurred for me when I was trying to build projects that use
'configure' and 'libtool'. These shell scripts interpret output badly because
of this text mode translation problem. It made it impossible (or at least VERY
difficult) to build the projects that I was working on. As I've said, I needed
to use the alternate environment, the default Mingw32 support provided by
Cygwin (all updated to 2.95, with Ander Norlander's Win32 APIs).
Jon Leichter
jon AT symas DOT com
> -----Original Message-----
> From: Earnie Boyd [mailto:earnie_boyd AT yahoo DOT com]
> Sent: Thursday, October 21, 1999 9:33 PM
> To: Jon Leichter
> Cc: cygwin AT sourceware DOT cygnus DOT com
> Subject: RE: B20.1: CR-LF translation not always handled properly
>
>
> Sorry, to have offended you, however, I've mixed cygwin and mingw32
> and not had
> problems. Pipes and redirection in cygwin default to binmode. Try `SET
> CYGWIN=nobinmode' before starting bash to see if it helps. It
> could very well
> be a cygwin bug. What version of cygwin are you using i.e.: what
> does `uname
> -a' give you?
>
> Earnie.
>
> --- Jon Leichter <jon AT symas DOT com> wrote:
> > Earnie,
> >
> > I had read about all of this real carefully before, and I thought I had
> > things
> > set up right. I'll explain what I have set up, and then you can tell me
> > whether or not it's still my setup that's wrong.
> >
> > I have my root file system mounted on my E: drive. Here's a sample of the
> > mount command:
> >
> > $ mount
> > Device Directory Type Flags
> > e: / native text!=binary
> >
> > Thus, I believe it is mounted in text mode. Furthermore, I do use
> other file
> > systems that are not mounted. I currently don't have the CYGWIN
> environment
> > variable set to anything. According to the User Guide, this (lack of a)
> > setting should default to text mode.
> >
> > Thus, all of the files that I access should be getting opened in text mode
> > when the appropriate tool is ran, e.g. 'sed' but not 'od'.
> >
> > When I first started having these problems, I tried changing
> modes to binary,
> > but it only added new problems. I think that setting was just
> wrong and not
> > what I needed.
> >
> > So my claim is that I have the rigth mode setting AND I still see these
> > problems. Note how I've mentioned that the 'grep' command DOES translate
> > CR-LF
> > to LF but that 'sed' and command substitution in 'bash' does NOT.
> If my mode
> > were wrong, I'd expect grep to be doing the 'wrong' thing too.
> >
> > Jon Leichter
> > jon AT symas DOT com
> >
> >
> > > -----Original Message-----
> > > From: cygwin-owner AT sourceware DOT cygnus DOT com
> > > [mailto:cygwin-owner AT sourceware DOT cygnus DOT com]On Behalf Of Earnie Boyd
> > > Sent: Thursday, October 21, 1999 7:55 PM
> > > To: Jon Leichter; cygwin AT sourceware DOT cygnus DOT com
> > > Cc: jon AT symas DOT com
> > > Subject: Re: B20.1: CR-LF translation not always handled properly
> > >
> > >
> > > It sounds to me as if your setup is broken rather than cygwin. To
> > > mix Mingw32
> > > (or any other win32 native package) and Cygwin you _have_to_have_
> > > text mounts
> > > and at times export CYGWIN=... nobinmode ... instead of binmode.
> > > The default
> > > for Win32 packages is to write the \r\n on line endings and you
> > > must process in
> > > text mode or modify the package to deal with the \r on the end
> of the line.
> > >
> > > Earnie.
> > >
> > > --- Jon Leichter <jon AT symas DOT com> wrote:
> > > > 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
> > > >
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Bid and sell for free at http://auctions.yahoo.com
> > >
> > > --
> > > Want to unsubscribe from this list?
> > > Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
> > >
> >
> >
>
> __________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com
>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -