X-Spam-Check-By: sourceware.org Message-ID: <452EA8DD.1070108@kionka.org> Date: Thu, 12 Oct 2006 13:43:09 -0700 From: "Daniel P. Kionka" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: shopt igncr not working References: <1160655422743 DOT antti DOT nospam DOT 1605718 DOT wGO_WJ9D1NlId3tB-z6Qig AT luukku DOT com> <20061012123406 DOT GA30908 AT trixie DOT casa DOT cgf DOT cx> <452EA386 DOT 9010201 AT qualcomm DOT com> In-Reply-To: <452EA386.9010201@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/