delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-SWARE-Spam-Status: | No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST |
X-Spam-Check-By: | sourceware.org |
MIME-Version: | 1.0 |
In-Reply-To: | <BANLkTinyfwi1Fkah76BAYX9YJwucsbUdLw@mail.gmail.com> |
References: | <4DD36619 DOT 1010401 AT hima DOT com> <BANLkTino_ZBUjCzbrmLezRJqjz2Y+04DCQ AT mail DOT gmail DOT com> <BANLkTinyfwi1Fkah76BAYX9YJwucsbUdLw AT mail DOT gmail DOT com> |
Date: | Tue, 7 Jun 2011 10:54:58 -0500 |
Message-ID: | <BANLkTikD_CYSqSg3FagsefDmx-rhaHGH1Q@mail.gmail.com> |
Subject: | Re: 1.7.9: Problem with line endings of Perl output redirected to a file with textmode mounting |
From: | "Craig A. Berry" <craig DOT a DOT berry AT gmail DOT com> |
To: | Reini Urban <rurban AT x-ray DOT at> |
Cc: | cygwin AT cygwin DOT com, pp <perl5-porters AT perl DOT org> |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com> |
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 |
On Tue, Jun 7, 2011 at 8:40 AM, Reini Urban <rurban AT x-ray DOT at> wrote: > 2011/5/24 Reini Urban: >> 2011/5/18 Sven Severus: >>> Ups! The original <cr> <lf> sequence starting at offset 4095 (0xfff) >>> became a three character sequence <cr> <cr> <lf>! The <cr> is duplicated! >>> >>> In other files created by Perl with output redirection I observed this >>> behaviour with every <cr> <lf> line ending, that is split by a 4096 byte >>> boundary (even multiple times in one output file). Line endings not >>> split by a 4096 byte boundary do not show this behaviour. >>> I this a bug of the output buffering mechanism of Cygwin Perl? >>> Or do I anything wrong? >>> Any answer is highly appreciated. Thanks in advance. >> >> Yes, this looks like a PerlIO buffering bug for MSWin32 and cygwin. >> The last char of the buffer is not stored when checking the first char >> of the new buffer. >> I think first we have to provide a sample test case to perl core. > > I could not reproduce it in perl core with the PerlIO :crlf layer, see > attached test. > I'm investigating cygwin buffer edge-case handling now. I don't see Perl versions mentioned here, but note that the default PerlIO buffer size was 4096 for many years until 5.14.0, at which point it became the larger of 8192 and BUFSIZ. So if you're testing with blead, you may see the behavior at a different offset than 4096, assuming this involves something getting tangled up between PerlIO buffer flushing and the Windows-specific crlf layer managing its line endings. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |