Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > If you didn't get a true value back from print, you didn't really put data in the file.

    Wow! That's a surprise to me, and I certainly don't check the return value of print in my own code. I guess an easy way to bundle this up would be to make print fatal in a block that prints to file handles, and trap with eval? Are there other (better) ways to handle this?
    --

    osfameron

    • I do not think you can use fatal with print as afair the way print works can not be expressed with a prototype

      perl -e'use Fatal qw(print);'
      Cannot make a non-overridable builtin fatal at /usr/share/perl/5.8/Fatal.pm line 108.

      Another thing worth remembering is print doesn't seem to return failure every time it fails. I think it returns success if you print to a file in a full filesystem ( or did when I checked on linux and hp a year or so ago ).
      • It does seem like sometimes I can print to a file and have no error code, if the disk was full. In that case, close should fail; I'm not sure why close's failing didn't make things work properly... I will investigate this further.

        Fortunately, I also patched to check that -s $file >= length $message.
        --
        rjbs
        • Checking the final length of the file is a good thing, but it is also a bit limiting. It can only be done when you know that the output is going to a real file on a real file system; if you do it if when you're accepting a "file name" from the user, you preclude the option of being given a device or a command pipeline instead of a file. That could limit the potential flexibility for using your program.