shopt igncr not working

Daniel P. Kionka dan@kionka.org
Thu Oct 12 20:43:00 GMT 2006


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/



More information about the Cygwin mailing list