This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Similar Bash 3.1.18 CR/LF Problem

On Wed, Oct 04, 2006 at 07:17:18PM -0600, Eric Blake wrote:
>Hash: SHA1
>According to Williams, Gerald S (Jerry) on 10/4/2006 11:06 AM:
>> Christopher Faylor wrote:
>>> The dilemma here is that I read other mailing lists besides
>>> cygwin where people are trying to use Cygwin but are close
>>> to giving up because it is so slow.  So, making bash faster
>>> for people who are using it correctly is very desirable. 
>> Which is why we need to get the patch in upstream. If you
>> can't make it faster, you can at least make what you're
>> comparing against slower. :-)
>There may be precedent - upstream already had a patch for djgpp that
>stripped \r.  But I also heard back from the upstream maintainer that I
>probably missed the cutoff for bash 3.2, since he has already built the
>release candidate, so I will have to keep it as a cygwin-local patch for
>another release cycle.

Am I understanding what this change does correctly?

It does not really fix the "CRLF problem".  Instead it just strips every
\r that it finds regardless of whether the \r is before a \n, right?

If this is right and you can do this level of surgery on bash's buffers
is it harder to detect \r\n because the \n may not be in the current
buffer so you don't know when to strip a \r at the end of the buffer?

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]