This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
Hi!

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.


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?

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?

Thanks,
Rob




-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]