Mail Archives: cygwin/1999/10/22/00:32:02
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 -