No, you need to post a trimmed down relevant sample that shows the same behavior. Maybe you've got a missing letter in a variable name and aren't using strict so it's not getting caught. Maybe you've neglected to append a newline to a print and you're suffering from buffering. Maybe you've called something that's causing a real problem down inside Mail::Message. No one here can diagnose that because you haven't shown the code that's not working. You've given no details, just a vague "something resembling this snippet of code in some context at some time isn't working for me".
Not that it's inconceivable that there's a problem with the module in question, but no one's going to be able to divine what might be going wrong without any actual real code exhibiting the behavior in question to paw over and figure out what might be going wrong.
Update: Something like this (which by the way works fine for me; sample output after the __END__):
#!/usr/local/bin/perl5.10.0
use strict;
use warnings;
use feature ':5.10';
use Mail::Box::Manager;
my $mgr = Mail::Box::Manager->new();
my $folder = $mgr->open( "$ENV{HOME}/Mail/outgoing" );
my $msg = $folder->message( 0 );
for my $header ( qw( subject from received bogus ) ) {
say "Msg $header: ", $msg->get( $header ) // 'UNDEF';
}
exit 0;
__END__
Msg subject: testing comp
Msg from: Mike Fletcher <REDACTED>
Msg received: UNDEF
Msg bogus: UNDEF
That's actual code that someone can grab, tweak the path to a mailbox for their environment, and attempt to duplicate your problem. It shows exactly what is being done when things don't behave (or are behaving as it does in this case since that message has no "Received" headers). Ideally you'd even include a sample message/mbox file which includes a "Received" header but the same code doesn't print it out (but that might be getting greedy :).
The cake is a lie.
The cake is a lie.
The cake is a lie.
|