rjbs vs. the perl email project

rjbs on 2006-02-02T04:44:35

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.

---

use fatal 'print'; ?

osfameron on 2006-02-02T08:18:55

> 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?

Re:use fatal 'print'; ?

link on 2006-02-02T09:24:45

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 ).

Re:use fatal 'print'; ?

rjbs on 2006-02-02T12:47:21

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.

Re:use fatal 'print'; ?

jmm on 2006-02-02T14:29:38

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.

Re:use fatal 'print'; ?

rjbs on 2006-02-02T15:58:28

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?"