This is the mail archive of the
cygwin-talk
mailing list for the cygwin project.
RE: Similar Bash 3.1.18 CR/LF Problem
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'i'm sorry i'll read that again'" <cygwin-talk at cygwin dot com>
- Date: Wed, 4 Oct 2006 18:37:42 +0100
- Subject: RE: Similar Bash 3.1.18 CR/LF Problem
- Reply-to: The Cygwin-Talk Maiming List <cygwin-talk at cygwin dot com>
On 04 October 2006 18:29, mwoehlke wrote:
> Dave Korn wrote:
>> On 04 October 2006 18:06, Williams, Gerald S (Jerry) wrote:
>>
>>
>>> Seriously, I'd have a hard time believing that supporting
>>> <CR><LF> endings would noticably impact performance if it
>>> were done as part of upstream BASH. Special-casing Cygwin
>>> (especially when you start doing things like checking for
>>> DOS paths, examining the first line, etc.) would impact
>>> performance, surely. So I agree--don't do that.
>>
>> That's a total non-sequitur. A piece of code will have the same impact,
>> whether it's included directly in the upstream sources, or whether it's a
>> cygwin local patch surrounded by #ifdef __CYGWIN__.
>
> "Your facts are out of order." :-D
Oh, I do beg your pardon, let me try that one again:
>> A piece of code will have the same impact, whether it's a
>> cygwin local patch surrounded by #ifdef __CYGWIN__, or
>> whether it's included directly in the upstream sources.
Are they in the right order now? ;)
cheers,
DaveK
--
Can't think of a witty .sigline today....