This is the mail archive of the
mailing list for the Cygwin project.
Re: Similar Bash 3.1.18 CR/LF Problem
On Wed, Oct 04, 2006 at 07:17:18PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html