X-Spam-Check-By: sourceware.org Message-ID: <452324B4.1030306@cygwin.com> Date: Tue, 03 Oct 2006 23:04:20 -0400 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060916 Fedora/1.5.0.7-1.fc4.remi Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Bash and CR/LF line-endings References: <000201c6e75c$97a8afe0$020aa8c0 AT DFW5RB41> In-Reply-To: <000201c6e75c$97a8afe0$020aa8c0@DFW5RB41> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Gary R. Van Sickle wrote: >> From: Eric Blake >> Sent: Tuesday, October 03, 2006 9:07 PM >> Subject: Re: Bash and CR/LF line-endings >> > [snip] >> Perhaps so, but that was a risk I was willing to take, since >> cygwin's stated goal is to provide a Linux emulation on >> Windows, and Linux users don't go creeping in cr/lfs. >> > > At the risk of being over-obvious, Linux users... use Linux. In such an > insular environment, perhaps they have the luxury of only using the One True > Text File Format (whatever that is). Actually, Windows users also have that > luxury, as long as they wish to remain in their own world as well. Where > the twain meet of course is where we run into issues, and the twain meet at > Cygwin. Used to, anyway. Linux users use Linux until they are forced to use Windows. When that happens, they tend to use Cygwin. Since Cygwin is intended to meet their needs, it should do so in a transparent way whenever possible. But there's cases where that isn't possible and, lo and behold, that's still in Cygwin. ;-) >>> So why was the solution of using the 1st line of the script >> (which, it >>> was claimed, is read anyway for other purposes) and base >> the seeking >>> behavior on the detection of cr/lf there, rejected? >> It is not rejected, merely unimplemented. My patches have >> focused on the minimal amount of code to get a decent >> workaround, and hacking the initial 80-character read of a >> file proved harder than hacking the input engine. >> If someone else (how about you?) were to submit a patch doing >> just that, then I would certainly review it and likely apply >> a derivative of it, in part because reviewing a patch is a >> much smaller time commitment on my part than me writing yet >> another workaround from scratch. >> >> Actually, if anyone is interested in pursuing this further, >> it may be worth auto-setting the igncr shopt according to the >> first line of the script, rather than the current behavior of >> defaulting that option to unset for every new bash >> invocation. Also, you must consider how things should work >> when stdin is a pipe containing \r\n data, since with pipes, >> you can't prescan the first line of input to see what it >> contains because you can't rewind afterwards. >> > > What's going to break if igncr is simply always on? Me poor head! ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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/