Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Wednesday February 01, 2006
11:44 PM

rjbs vs. the perl email project

[ #28554 ]

I really like the Perl Email Project, in theory. Lately it's been getting my goat, due to weird interfaces, backwards compatibility glitches, and one particularly troublesome bug.

Tomorrow I plan to go on the offensive against Email::Send, trying to improve the interface, at least for my own benefit. I want to be able to specify the envelope sender and recipient, I more standard return values, and maybe just a more standard argument passing system. Simple is good, but I can't afford to box anything into something so simple as to be constrictive. Anyway, time will tell whether I should actually be worried. Hopefully just twenty-four hours will be enough.

Today's bug was a serious pain. Let me remind all you Perl programmers: if you print to a filehandle, check the result of print. If you didn't get a true value back from print, you didn't really put data in the file. Even if you could create the file and close the filehandle successfully, if you didn't print, you didn't deliver your mail!

Hopefully Email::LocalDelivery will soon be patched... and now I see that some other useful patches need to be applied, like the one to make Email::Send::SMTP fork-safe. Maybe tomorrow will be a good day for Perl Email, if I can get my butt in gear.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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?


    • 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/ 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.
        • 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.
          • Sure, but fortunately in this case I didn't define the API, and can rely on real filenames going to a real filesystem. ...should I be concerned that I think it's OK to say, "I didn't define the API and can therefore rely on it?"