On Apr 20, 2011, at 5:03 PM, Dr. Martin P.J. Zinser wrote:

> Hello,
> 
> sorry to be a pain, but here is another case of the spurious linebreak.
> Environment is OpenVMS IA64 8.3-1H1, Perl 5.12.3 with useperlio defined.

Since perlio is the default, do you mean that you disabled it?

> 
> I am using Perl with the CGI module to dynamically create a medium sized 
> table (a few hundered rows and 6 columns). The script works fine on 
> Perl 5.8.8 on OpenVMS Alpha.
> 
> When accessing the script via a webserver, spurious linebreaks are inserted 
> into the table, causing garbled output (e.g. a <td ends up as <t\nd, which 
> also
> a forgiving parser will not process correctly). Running the same script in 
> debug mode and sending the output to a file does <<not>> show the spurious 
> linebreaks.
> 
> Shorter tables generated by the same script work fine also with 5.12.3 .
> 
> I've already changed the script to write the table one row at the time to the 
> CGI output, but that this not resolve the issue.
> 
> Any ideas and/or hope that this will be resolved with the soon to be released 
> 5.14?

5.14 is in deep code freeze at the moment, so if it's a unique problem that 
hasn't been reported before, no, it won't be fixed in that version.  If you are 
writing lines longer than 4K to record-oriented files, you'll still get 
linebreaks at 4K intervals in 5.12.3, but 32K intervals in 5.14.0 (you can get 
the same effect in 5.12.3. by s/4096/32768/ in perlio.c).

I can't really analyze the current problem without more information.  Does the 
problem happen on read or write?  What does SHOW DEVICE/FULL on your 
"webserver" give you?  In other words, is it a mailbox or a socket or a global 
section or what that Perl is writing to?  And are you sure that the linebreaks 
aren't already there when reading the data in (using what, DBD::Rdb?).  How big 
are the I/O operations?  Etc.

________________________________________
Craig A. Berry
mailto:craigbe...@mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to