homepage Welcome to WebmasterWorld Guest from 54.211.157.103
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
Forum Library, Charter, Moderators: coopster & jatar k & phranque

Perl Server Side CGI Scripting Forum

    
Mime::Lite error
"Strict refs"
rocknbil




msg:3881311
 8:39 pm on Mar 29, 2009 (gmt 0)

Linux server, Fedora, moving a client from an older host to new one, using Mime:Lite for attachments. Has worked for years but in the new environment gets

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;
}

 

krugs




msg:3881353
 10:32 pm on Mar 29, 2009 (gmt 0)

I would try removing the scrub method.....


scrub

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

rocknbil




msg:3881355
 10:43 pm on Mar 29, 2009 (gmt 0)

Thanks krugs, but I doubt scrub is it, that just clears headers from the message . . . note it dies at trying to set Type (which can be a hash, for multiple attachments . . . )

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.

krugs




msg:3881491
 5:02 am on Mar 30, 2009 (gmt 0)

Did you try removing srub? Because when I looked in the source of MIME::Lite the line number where the error occurs appears to be in the scrub methods code. And the problem does appear to be associated with the headers.

site_perl/5.8.8/MIME/Lite.pm line 1690 <-----

rocknbil




msg:3882667
 7:17 pm on Mar 31, 2009 (gmt 0)

Thank you krugs, honestly it was at the end of a 12 hour day on a pro-bono project and I was at that point of patching it and getting out. I didn't go that deep into the module.

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.

krugs




msg:3882861
 2:22 am on Apr 1, 2009 (gmt 0)

Weird, I have no idea why being in a subroutine would cause different behavior. Sorry about the pro-bono work. My last project turned out to be pro-bono too, because the jerk took my work and never paid me! $1,000 worth of time, thats the last time I trust anyone again, from now on I use an escrow service or the custmer pays upfront.

rocknbil




msg:3883110
 2:40 pm on Apr 1, 2009 (gmt 0)

Well, this one is volunteer work. I've had my share of "oops I stepped in it's." But in this case, it's one of the projects I volunteered to a good cause . . .

I just hate leaving issues unresolved, for the time being it's "working" but not "right."

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Perl Server Side CGI Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved