This is the mail archive of the
mailing list for the Cygwin project.
Re: shopt igncr not working
I was writing a similar email when I got Rob's...
I was surprised when all my bash scripts failed after I upgraded
(because of the CR/LF change). One of the most important rules of a
stable product is backwards compatibility. I cannot track down every
bash script and add "shopt -s igncr", and no one should ever have to.
If a new version of a program is incompatible, it should be renamed as a
new program, like baash (bourne again again shell).
Maybe the developers do not realize how successful Cygwin has become. I
have used Cygwin from the beginning (I was a beta tester). I used to
have to push hard to convince the company to take the risk of using
Cygwin, but now I see companies using it before I join. The software
industry relies on Cygwin, and relies on it getting better with every
release. If a release randomly causes all scripts to fail, I may be
forced to convert everything to Perl.
I am disappointed with the developer response. They insist that the
"right" solution is to remove CRs. Cygwin is not just a project for
Unix nerds anymore! I love Unix, too, but I accept that Windows uses
CR/LF. Bash scripts are text files; you must be able to edit them with
notepad, and when you check them into source control, they get checked
out with CR/LF like all text files.
Another minor criticism is that you transitioned too fast. When you add
a required setting, you should first add it as an optional (ignored)
setting. I added "shopt -s igncr" to some files, but gave up and
down-rev'd bash, and then got errors on those scripts (shopt: igncr:
invalid shell option name). You should have added it as a no-op setting
and waited until it got into the field so users could switch bash
versions without changing all their scripts.
Someone recommended changing the default to ignore CRs. That would give
backwards compatibility and would allow people needing the extra speed
to disable it.
Rob Walker wrote:
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 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?
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
b), i.e., use the tool the way it was designed to be used.
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 this?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html