Hi, we are currently testing perl 5.10.1 in our development environment. We also ran into some issues which i did some initial analysis on. Unfortunately, i am not directly involved in testing 5.10.1 and didn't find time to get as far as collecting exact details in an isolated test case yet.
There are two issues i have off the back of my mind: 1) Random problems with carriage return and vmsopen() I suspected it had something with buffering in connection with vmsopen(). For our purposes, i changed the record format from "rfm=var" to "rfm=stmlf" and files looked fine (Although this does smell like a regression from 5.8.6, the modules in our case probably should not have been using "rfm=var" in the first place...) 2) File::Spec::VMS->catpath() was making some "vmsify path" routine create illegal VMS filenames like "LOG:[]filename.txt" instead of LOG:filename.txt (which made File::Copy->copy() break) To continue our tests, we added something similar to "s/:[]/:/" as a kludge in File/Spec/VMS.pm Regards, Mudiaga Obada On 22.04.2010 16:25, Craig A. Berry wrote: > > On Apr 21, 2010, at 11:55 PM, Carl Friedberg wrote: > >> About 7 weeks ago, I put 5.10.1 into production. It looked good until >> the overnight production ran, and then all hell broke loose. I did >> not have time to poke around, but the symptom was that completely >> trivial perl scripts failed, with extra line breaks being thrown into >> the output. I put the old version back, and everyone was happy again. >> The offending (trivial) perl script was replaced with an awk script. > > > First of all, it's good to see people using Perl in production on > VMS. Obviously it's a bit distressing to find out about an impediment > to using the current or previous version just after a new major > version has been released. I think the next steps are to narrow down > further where the behavior changed by testing against 5.8.9 and > 5.10.0. If anyone has the opportunity to do that, please speak up. > > The unwanted line break in Martin's example occurs at exactly 4048 > bytes into the file. There is likely a buffer involved, but not a > mailbox buffer since as far as I can tell there's no mailbox > involved. Of course it's possible this example dodged a bullet by > hitting a record boundary earlier on and the real magic number is > something less than 4048. I'm going to have a crack at narrowing this > down further. > ________________________________________ > Craig A. Berry >
