Hi Craig, I saw this a week or so ago but didn't have time to respond earlier ... I hope this message is still useful. >This is right after the perlio layer has called down to the unixio >layer to get the file open. We have an fd, so we can do an fstat() on >that and retrieve the record format from the VMS-specific bits of the >stat structure. Then I check to see if it's a regular file (not a >device like a mailbox that may need to carry binary data) and that the >record format is either variable or variable with fixed control. If >these conditions are met, I enable the line buffering option on that >filehandle. So far so good ... >I have tested this and it works for situations similar to Martin's >original report, and it does not introduce any new test failures in >the test suite. But what situations, if any, does this break? I'm >assuming that if the record format is FAB$C_VAR or FAB$C_VFC, the >records will never contain binary data with embedded newlines. Is >that true? What other assumptions am I making that I shouldn't? The great advantage of the VAR and VFC formats (compared to the various Stream formats) is that you *can* have embedded newlines and other non- printable characters in the record. So it's quite conceivable that a program might right "binary" data to a VAR or VFC file. On the other hand it would not be common Perl practice to do so. When I'm writing programs I assume that each 'print' statement will result in one output record. I susppose you could arrange for each 'print' to be followed by a flush to disk at that point, but of course performance would probably suffer. Just my 2c worth. Regards, Jeremy BeggThread Previous | Thread Next