Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: "Jon Leichter" <jon AT symas DOT com>
To: <earnie_boyd AT yahoo DOT com>
Cc: <cygwin AT sourceware DOT cygnus DOT com>
Subject: RE: B20.1: CR-LF translation not always handled properly
Date: Thu, 21 Oct 1999 22:12:14 -0700
Message-ID: <003001bf1c4c$00b92890$a0418218@bass.we.mediaone.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <002f01bf1c4b$3d1e15d0$a0418218@bass.we.mediaone.net>

Oops... I stated one thing backwards...

In my test program, stdin starts in textmode. I had to explicitly set it to
binmode to see a difference.

This suggests that 'sed' must be setting stdin to binmode, but I wouldn't know
why.

Jon


> -----Original Message-----
> From: cygwin-owner AT sourceware DOT cygnus DOT com
> [mailto:cygwin-owner AT sourceware DOT cygnus DOT com]On Behalf Of Jon Leichter
> Sent: Thursday, October 21, 1999 10:07 PM
> To: earnie_boyd AT yahoo DOT com
> Cc: cygwin AT sourceware DOT cygnus DOT com
> Subject: RE: B20.1: CR-LF translation not always handled properly
>
>
> 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
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com