This is the mail archive of the
mailing list for the Cygwin project.
Re: shopt igncr not working
Christopher Faylor wrote:
On Thu, Oct 12, 2006 at 01:20:22PM -0700, Rob Walker wrote:Don't get me wrong. Cygwin's the best Linux-like environment I've ever
used. Barring a fix, a workaround is what I'll employ if possible. But
each workaround adds to the tribal knowledge base, making Cygwin harder
to sell to my teams. Up until recently I'd tell them to just "go get
the latest Cygwin" and everything will work.
Christopher Faylor wrote:
On Thu, Oct 12, 2006 at 03:17:02PM +0300, Antti Tyrv?inen wrote:
Saying cygwin's bash wasn't designed to handle CRLF is a lot like
Hi!b), i.e., use the tool the way it was designed to be used.
Installed latest cygwin and I met problems with bash and scripts which
are in DOS format.
$ bash --version
GNU bash, version 3.1.17(9)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.
I read the mailing lists and I also tried to add ' shopt -s igncr;#' in
the beginning of the script, but it didn't work. In my opinion, this is
bad solution if I have to edit all my existing scripts.
All works fine with bash 3.1.6.
What I should do?
a) install bash 3.1.6 and wait for new
b) install bash 3.1.9. and convert all my scripts to UNIX format
saying that cygwin's bash (as previously released all these years)
wasn't designed to work with the rest of Windows. This might actually
be the case, but I don't understand the point. If you don't want to
work with Windows, why release for Windows?
So, why were you asking for help if you weren't going to actually avail
yourself of it?
You can read the first few paragraphs of the Cygwin web site forYes, thanks. Are you saying that this should be interpreted as "don't
try to use Cygwin with anything else in Windows?" The great thing about
Cygwin has been its interoperability. The people who are moaning and
groaning have found Cygwin to be a powerful, consistent environment for
working on Windows with other Windows programs.
information about what Cygwin is.
If you're referring to the performance gain realized, I think it could
have been accomplished (if not as trivially) without breaking CRLF
handling. This seems to be indicated in other posts, ones that talk
about reworking line parsing.
Many, many other cross-platform products make allowances for CRLF
(version control systems are a prime example) to maximize
compatibility, and thereby their usefulness, on Windows. Cygwin's
recent changes (with make and bash) here has put a real crimp in my
plans to depend on cygwin for a portable build environment.
Just curious, is there a goal or strategy that drives changes like
You may not have been paying attention but this has already been
explained a few times.
I understand that the 'make' change was initially done to alleviate some
recurring tedium in Cygwin releases, and that an upstream patch is now
Actually, though, I was asking about a bigger-picture strategy. One
that appears to be steering Cygwin away from interoperability of the
past, towards a more rigid interpretation of what Cygwin's suitable uses
are. Do you have a set of guiding principles you consult when deciding
the fate of Cygwin? Who do you consider Cygwin's customers to be?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html