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 Begg
