«

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

wrote in news: oups.com:

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

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

Sinan

--
A. Sinan Unur <>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/cl...uidelines.html

wrote:
> 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....
>

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

wrote:

> 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'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
--
Our three weapons are fear, surprise, and ruthless efficiency...
and an almost fanatical devotion to the Pope....
http://www.ai.mit.edu/people/paulfitz/spanish/t1.html

The Spanish Inquisition wrote:

> wrote:
>
>> 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'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.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

John Bokma wrote:
> The Spanish Inquisition wrote:
>
>
>> wrote:
>>
>>
>>>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'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.

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
--
Our three weapons are fear, surprise, and ruthless efficiency...
and an almost fanatical devotion to the Pope....
http://www.ai.mit.edu/people/paulfitz/spanish/t1.html

The Spanish Inquisition wrote:

> John Bokma wrote:
>> The Spanish Inquisition wrote:
>>
>>
>>> wrote:
>>>
>>>
>>>>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'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.
>
> 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.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

John Bokma wrote:

> The Spanish Inquisition wrote:
>
>>John Bokma wrote:
>>
>>>The Spanish Inquisition wrote:
>>>
>>>> wrote:
>>>>
>>>>>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'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.
>>
>>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 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.

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

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.

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

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
--
Our three weapons are fear, surprise, and ruthless efficiency...
and an almost fanatical devotion to the Pope....
http://www.ai.mit.edu/people/paulfitz/spanish/t1.html

The Spanish Inquisition wrote:

> John Bokma wrote:

:

>> Have you ever used MIME::Lite?
>
> 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.

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

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

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.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

John Bokma wrote:

> The Spanish Inquisition wrote:
>
>>John Bokma wrote:
>
>>>Have you ever used MIME::Lite?
>>
>>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.

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.

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

Possibly.

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

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

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

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.

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

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

>>Some of them are quite complicated
>
> 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?

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

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.

>>>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...
>
> 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
--
Our three weapons are fear, surprise, and ruthless efficiency...
and an almost fanatical devotion to the Pope....
http://www.ai.mit.edu/people/paulfitz/spanish/t1.html