Perl, Mail, Mime & Multipart....

[amerar]

Hi,

I have a Perl script which sends out emails for us. I want to change
it such that it sends out both a text portion and an HTML portion.

From what I have read, with a multipart/mixed header and the proper

boundary tagbs, the email client will decide which is the best to
display.

I have pasted my code below. I am testing with Netscape Messenger.
And, no matter what, it always displays both text & html.

Maybe someone can see if I've made some errors or something....

Thanks in advance.

$smtp->datasend("From: $from1\n");
$smtp->datasend("Reply-To: $replyto\n");
$smtp->datasend("To: $email\n");
$smtp->datasend("Subject: $subject\n");
$smtp->datasend("Mime-Version: 1.0\n");
$smtp->datasend("Content-Type: multipart/mixed;\n");
$smtp->datasend(" boundary=\"theBoundary\"\n\n");
$smtp->datasend("\n\n");
$smtp->datasend("--theBoundary\n");
$smtp->datasend("Content-Type: text/plain; charset=us-ascii\n\n");
foreach $line (@text_letter) {
$smtp->datasend("$line\n");
}
$smtp->datasend("\n\n");
$smtp->datasend("--theBoundary\n");
$smtp->datasend("Content-Type: text/html; charset=us-ascii\n\n");
foreach $line (@html_letter) {
$smtp->datasend("$line\n");
}
$smtp->datasend("\n--theBoundary--\n");

Arthur

 

[A. Sinan Unur]

I have a Perl script which sends out emails for us. I want to change
it such that it sends out both a text portion and an HTML portion.

boundary tagbs, the email client will decide which is the best to
display.

I have pasted my code below.

<URL: http://search.cpan.org/~yves/MIME-Lite-3.01/lib/MIME/Lite.pm#Create_a_multipart_message>

Sinan

 

[RedGrittyBrick]

Hi,

I have a Perl script which sends out emails for us. I want to change
it such that it sends out both a text portion and an HTML portion.

boundary tagbs, the email client will decide which is the best to
display.

I have pasted my code below. I am testing with Netscape Messenger.
And, no matter what, it always displays both text & html.

Maybe someone can see if I've made some errors or something....

Perhaps you need multipart/alternative rather than multipart/mixed.

 

[The Spanish Inquisition]

I have a Perl script which sends out emails for us. I want to change
it such that it sends out both a text portion and an HTML portion.

boundary tagbs, the email client will decide which is the best to
display.

I'm fairly lazy (hey, it's supposed to be a virtue for a programmer), so
I took the following approach. I took the source for a sample mail I
created in Thunderbird (any mail app will do), stripped out the contents
and replaced it with $variable names. Pasted the result in my script
(under the __DATA__ line).

The script reads in the mail template from the <DATA> handler, calls
eval() to substitute the variables and sends the mail out with Net::SMTP.

Ximinez

 

[John Bokma]

I'm fairly lazy (hey, it's supposed to be a virtue for a programmer), so
I took the following approach.

That's not lazy... Lazy is going to CPAN and then use the right module for
the job. So you don't have to worry about all those details, testing, etc.

 

[The Spanish Inquisition]

The Spanish Inquisition wrote:



That's not lazy... Lazy is going to CPAN and then use the right module for
the job. So you don't have to worry about all those details, testing, etc.

These modules are complicated enough to require testing. Detailed enough
to require tinkering and tiring activities like documentation reading
(brrr). I just let Thunderbird do all the work for me and copy&pasted a
little.

And then there are CPAN modules that simply refuse to install without
errors, or 'force' install with some errors, so you're never quite sure
whether they'll run correctly or not.

I remember that time when I tried to move a script that used POE to a
different machine. Unfortunately POE wouldn't install on the new system
for some obscure reason. There goes portability...

CPAN modules are great for many reasons, but if there's an easy way to
do it without another module dependency I'll take it.

Ximinez

 

[John Bokma]

These modules are complicated enough to require testing. Detailed
enough to require tinkering and tiring activities like documentation
reading (brrr).

Have you ever used MIME::Lite?

I remember that time when I tried to move a script that used POE to a
different machine. Unfortunately POE wouldn't install on the new
system for some obscure reason. There goes portability...

But is that CPAN/POE/Perl or the "other machine".

CPAN modules are great for many reasons, but if there's an easy way to
do it without another module dependency I'll take it.

Reinventing the wheel by cutting off 4 corners of a rock is not the easy
way.

 

[The Spanish Inquisition]

Have you ever used MIME::Lite?

I have tried it, actually. I found the template method easier. Not only
to avoid using the module but also because it allows me to store prefab
message templates in files and have them filled in by the perl mailer.
Works pretty well for my purposes.

But is that CPAN/POE/Perl or the "other machine".

Does it matter? Not all CPAN modules are perfect. Some of them are quite
complicated and won't compile in certain circumstances. These
circumstances can't always be avoided.

Reinventing the wheel by cutting off 4 corners of a rock is not the easy
way.

Cute. We're not talking wheels here, though. We're talking alternative
solutions to creating simple mail messages. Both solutions work and both
have their advantages. Sorry to have stumble on a dogma here...

Ximinez

 

[John Bokma]

John Bokma wrote:
:


I have tried it, actually. I found the template method easier.

So you gave up soon, and now create code that's hard to maintain for
others. Yes, MIME::Lite takes like 10 minutes to understand, and yes, I
know reading doesn't look productive, but pressing all those keys the
whole day looks like a lot is going on. But no serious programmer should
do what you did.

Not
only to avoid using the module but also because it allows me to store
prefab message templates in files

Since you haven't checked out on MIME:Lite, you missed that you can do
this to, I guess.

and have them filled in by the perl
mailer. Works pretty well for my purposes.

Yes, you created hard to maintain code, not a big deal if it's your
tool, but a big deal if others have to maintain it. Moreover, you missed
an opertunity to learn a new module, a big loss IMNSHO.

Does it matter?

Of course it does, you rant about CPAN but the problem is very likely
the machine. How can CPAN fix the problems on your machine?

Not all CPAN modules are perfect.

Never said so. But if everbody does it your way we get a lot, and I mean
a lot, of less than perfect code that's extremely hard to maintain, and
full of bugs. CPAN modules are not perfect, but if everybody uses them
they can get better. If you find a problem or have a suggestion it can
be fixed/added.

Some of them are quite complicated

If you consider a module complicated I hate to guess your Perl skills.
Programming is complicated, period.

and won't compile in certain circumstances. These
circumstances can't always be avoided.

But you can report them, or contribute for the free use (and huge time
saver) the others give you, and help to fix the problem. Most modules
are made in spare time, you can't expect everybody to have access to
several set ups and make everything work so you can have a free ride.

Contribute and make it grow.

Cute. We're not talking wheels here, though. We're talking alternative
solutions to creating simple mail messages. Both solutions work and
both have their advantages. Sorry to have stumble on a dogma here...

Yours has only an advantage for you, and maybe that advantage is based
on misunderstandig since you sound like someone who measures
productivity by the number of keystrokes/hour.

 

[The Spanish Inquisition]

So you gave up soon, and now create code that's hard to maintain for
others. Yes, MIME::Lite takes like 10 minutes to understand, and yes, I
know reading doesn't look productive, but pressing all those keys the
whole day looks like a lot is going on. But no serious programmer should
do what you did.

Sure, so I'm not a serious programmer. That didn't you take long to
figure out, did it? I guess ten of thousands of satisfied users and
mainatinable systems that run for years on years don't count. No, my
less-than-dogmatic stance on reuse of modules dequalifies me completely.

It takes all sorts, John. I may not be your idea of an ideal programmer,
but I know I have some qualities that many other programmers miss. I
know some people who are pretty glad I'm not like other programmers.

Since you haven't checked out on MIME:Lite, you missed that you can do
this to, I guess.
Possibly.


Yes, you created hard to maintain code, not a big deal if it's your
tool, but a big deal if others have to maintain it. Moreover, you missed
an opertunity to learn a new module, a big loss IMNSHO.

You can't learn everything as every programmer knows...

Of course it does, you rant about CPAN but the problem is very likely
the machine. How can CPAN fix the problems on your machine?

I'm not saying it should. I'm saying that dependance on complicated
modules may hurt me (and my coworkers) in certain cases. It's no-one's
fault in particular, but it's something to consider when you have to
choose between rolling your own and using someone else's work.

Never said so. But if everbody does it your way we get a lot, and I mean
a lot, of less than perfect code that's extremely hard to maintain, and
full of bugs. CPAN modules are not perfect, but if everybody uses them
they can get better. If you find a problem or have a suggestion it can
be fixed/added.

Agreed there, but hey, I never said I wasn't lazy.

If you consider a module complicated I hate to guess your Perl skills.
Programming is complicated, period.

I consider some modules complicated. POE is a good example. It good
stuff but it depends on many other modules and I've seen it not-compile
on some occasions. I consider other modules less complicated and some
are downright simple.

I've nothing against using modules in general. Hell, who could be a
serious perl programmer without using and writing modules?

But you can report them, or contribute for the free use (and huge time
saver) the others give you, and help to fix the problem. Most modules
are made in spare time, you can't expect everybody to have access to
several set ups and make everything work so you can have a free ride.

Contribute and make it grow.

Guilty as charged, I should do more of that. Unfortunately not all bug
reports are acted on or even reacted on, which doesn't always help with
motivation. Analysing what exactly is going wrong can be a lot of work.

Yours has only an advantage for you, and maybe that advantage is based
on misunderstandig since you sound like someone who measures
productivity by the number of keystrokes/hour.

No, not exactly. Sometimes I spend hours polishing stuff until it's just
right and sometimes I just do it the quick way. Sometimes I reconsider
later and do it right after all. Pretty much the way most people work, I
guess... (but then again I'm not a real programmer eh?)

Gee, I always liked the relaxed attitude of the Perl crowd, whatever
happened to that?

Ximinez

 

[Alan J. Flavell]

Sure, so I'm not a serious programmer. That didn't you take long to
figure out, did it? I guess ten of thousands of satisfied users and
mainatinable systems that run for years on years don't count. No, my
less-than-dogmatic stance on reuse of modules dequalifies me
completely.

Your apparent unwillingness to step right up and discuss the
substantive issues raised by John B does rather convey a message, you
know.

If you've been so widely active as you say, one wonders how many
maintenance programmers are cursing your name in the meantime (or
maybe they just tossed the code out and started again, as so often
happens with hand-knitted code).

You can't learn everything as every programmer knows...

No disagreement there. However, using that as an excuse for publicly
refusing to learn more seems to me to be a sub-optimal way to proceed.

 

[The Spanish Inquisition]

Your apparent unwillingness to step right up and discuss the
substantive issues raised by John B does rather convey a message, you
know.

Oh yes? What message is that? That I suck at my job?

If you've been so widely active as you say, one wonders how many
maintenance programmers are cursing your name in the meantime (or
maybe they just tossed the code out and started again, as so often
happens with hand-knitted code).

One wonders, but one doesn't know, does one? Tossing code out and
starting over again can be a very healthy approach in my experience. One
learns, doesn't one?

No disagreement there. However, using that as an excuse for publicly
refusing to learn more seems to me to be a sub-optimal way to proceed.

Where did I publicly refuse to learn? When faced with a problem I once
chose a simple homebrew solution instead of an available canned one. How
is that "Publicly refusing to learn"?

Or is refusing to agree with a fundamentalist application of principles
'refusing to learn'. What do you want me to do? Confess? Repent?

I for one wouldn't hire a programmer who demonstrates such rigidity as I
meet here. I rather work with flexible people. But then again, I don't
have to go begging for Perl jobs on the web, quite the contrary actually.

Ximinez

 

[John Bokma]

Oh yes? What message is that? That I suck at my job?

No: that what you did, copy the source of a Thunderbird email message
and tweaking, is something I certainly wouldn't recommend if others have
to maintain the code at a point in time.

As I stated: spending one hour, or even two, at studying MIME::Lite will
give you the knowledge for not only solving the specific problem you
had, but will also give you something that might come in handy in the
feature.

I admit that not all CPAN modules are perfect, but as I stated, they get
better if people use them, instead of making up their own stuff.

At one time I was working on a Perl application that had 600+ (!) hand
coded Perl modules. About 6 people had been working on it, after each
other. Quite a lot of modules had code that was redundant, either
because someone else had added the code to another module, or worse, it
was a copy paste job.

Because everything was programmed in a hurry (since programming =
pressing keys must have been the impression they, or at least the
manager had) there was *zero* documentation.

Now I claim that a lot of those modules could have been replaced by CPAN
stuff. Yes, in some cases a wrapper would have been required.

Oh, I was replacing a programmer who gave up after 3 months, who
replaced a programmer who gave up after 3 months. I "left" them after a
similar time (I got fired, for non-related things, if you want to know,
email me). Anyway, I was already looking around for a different job.

If a module does x% of what you want, it might save you time. If it's a
well known module, and I think I can say that about MIME::Lite, you
might make your code easier to maintain, since there is a probability
that other programmers understand a part of your code, because they have
seen it before.

One wonders, but one doesn't know, does one? Tossing code out and
starting over again can be a very healthy approach in my experience.
One learns, doesn't one?

If you can toss out a CPAN module, and replace it by better code, please
do so. You benefit, and maybe I benefit. And if your code is better, the
person who is going to maintain your code might have already seen it.

Or is refusing to agree with a fundamentalist application of
principles 'refusing to learn'.

I consider "my code is better than yours (CPAN)" quite a
fundamentalistic view :-D

What do you want me to do? Confess? Repent?

I for one wouldn't hire a programmer who demonstrates such rigidity as
I meet here.

And I wouldn't hire a programmer who says: I copied the source of an
email and tweaked it a bit, because it was faster then reading CPAN
documentation :-D Especially since I might have to maintain that code.

I rather work with flexible people.

Me too. And going to CPAN, picking a module, and taking the time to
learn it is what I call fexible. Copy and pasting something and tweaking
until it works, is not programming in my book.

I know Perl is often used to write run once programs. But I started to
keep those "run once" scripts, and notice that I often re use them,
because I forced myself to even code what I consider run once code in
such a way that I still can read it after 2 months.

But then again, I don't
have to go begging for Perl jobs on the web, quite the contrary
actually.

I have to do that, for several reasons.

 

[Alan J. Flavell]

Oh yes? What message is that? That I suck at my job?

So you prove incapable of discussing substantive issues without
reacting to them as a personal affront. Bye.

 

[David Combs]

So you prove incapable of discussing substantive issues without
reacting to them as a personal affront. Bye.

It does seem that you guys are attacking him.

And he's not saying that others should do the email-thing the way
he does, only that he found that it worked for him.

Besides, two hours of hard concentration on something (Mime::Lite?)
during a packed-full day of putting out fires, is a lot to ask.

(Do you have two hours available to learn some package that, say,
because of your particular work, you might well never use again?)

Looks like a one-sided religious war starting-up. :-(


David