Can't use string ("multipart/mixed") as a HASH ref while "strict refs" in use at /server/path/to/perl5/site_perl/5.8.8/MIME/Lite.pm line 1690.....
The difference is in setting up his server, I cpan'ed the latest version of Mime::Lite and something is different. I know this has to do with hard/soft references, but I'm just not seeing it.
I've pasted the subroutine below, it's standard Mime::Lite usage.
I set up a test bed inline, and it runs fine, but when I do this, I'm hosed. Any ideas?
Script is not using strict and is one of those legacy take-over-my-mess projects, it would take days to clean it all up to run without warnings.
sub local_mail {
my ($to,$from,$subject,$body,$attachment,$str,$msg);
($to,$from,$subject,$body,$attachment) = (@_);
$body .= qq¦
============================================
$home
============================================
¦;
if (($attachment ne '') && (-f "$root/$datadir/$attachment")) {
$msg = MIME::Lite->new(
From => "$from",
To => "$to",
Subject => "$subject",
Type => 'multipart/mixed'
);
$msg->attach(
Type => 'TEXT',
Data => "$body"
);
$msg->attach(
Type => 'application/octet-stream',
Path => "$root/$datadir/$attachment",
Filename => "$attachment",
Disposition => 'attachment'
);
}
else {
$msg = MIME::Lite->new(
From => "$from",
To => "$to",
Subject => "$subject",
Data => "$body"
);
}
$str = $msg->as_string;
$msg->print(\*SENDMAIL);
$msg->scrub;
$msg->send;
}
scrubInstance method. This is Alpha code. If you use it, please let me know how it goes. Recursively goes through the "parts" tree of this message and tries to find MIME attributes that can be removed. With an array argument, removes exactly those attributes; e.g.:
Besides that I see nothing in your snippet that would produce the error.
However, I have a "workaround," it's just not a GOOD one.
I commented out the strict line at the head of Mime:Lite. This isn't a solution . . . it should run under strict. But now my programs are all working this way.
What's odd, like I say, in an "inline" test bed, it was fine. It only croaks when I put it in a subroutine. I tried another experiement with a simplified version, extracted from my program, and it ran . . . just never sent any mail.
I figure it's a problem with the way the original program is coded. Still on the blocks, haven't given up on setting it right, but it's off my desk . . for today.
However, I returned to it today and as you say, removing scrub worked - but when it's inline, and not in a subroutine, scrub() works without a hitch. (Also allowed me to return to use strict; in the module, whew . . . )
Unfortunately, this is a vital piece for this project; the emails *must* be plain text with attachments. If you don't scrub() it will give you this prior to the mail body:
Content-Disposition: inline
Content-Length: 2005
Content-Transfer-Encoding: binary
Content-Type: text/plain
I got most of it to work by specifying the headers to scrub,
$msg->scrub(['content-disposition', 'content-length','content-transfer-encoding','content-type']);
which now leaves me with this, which is equally ugly:
This is a multi-part message in MIME format.
--_----------=_1238525041139060
So, for the time being, they're going to have to live with the content headers in the mail body.
Because of the inline/subroutine puzzle, I still think it's something in the original program (not the mime module.)
This is why I don't like using modules. :-(
P/S., I remember that "alpha code" comment from years ago . . . when it WORKED . . . figured it was just a legacy oversight in the documentation.