X-Spam-Check-By: sourceware.org
Message-ID: <452EFDDB.1010301@qualcomm.com>
Date: Thu, 12 Oct 2006 19:45:47 -0700
From: Rob Walker <rwalker AT qualcomm DOT com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com, 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> <20061012212011 DOT GA8535 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20061012212011.GA8535@trixie.casa.cgf.cx>
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: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Christopher Faylor wrote:
> On Thu, Oct 12, 2006 at 01:20:22PM -0700, 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?
>>     
>
> So, why were you asking for help if you weren't going to actually avail
> yourself of it?
>   
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.

> You can read the first few paragraphs of the Cygwin web site for
> information about what Cygwin is.
>   
Yes, 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.

>   
>> 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?
>>     
>
> You may not have been paying attention but this has already been
> explained a few times.
>   
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.

I understand that the 'make' change was initially done to alleviate some 
recurring tedium in Cygwin releases, and that an upstream patch is now 
available.

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?

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/