Trouble in using MIME::Lite 1

[lcs01]

Experts,

I wrote a small testing code to send email with an attachment using MIME::Lite. I can receive the email with the attachment. However, the size of the attachment is always ZERO bytes.

The following is my code:

use strict;
use MIME::Lite;

my $srceDir = './';
my $filename = $ARGV[0];
my $file = $srceDir.$filename;
if(-e $file) {
  print "File '$file' exists!!\n";
}
else {
  print "File '$file' does NOT exist!!\n";
  exit 1;
}

my $txt = "This is a test to send an email with an attachment '$file'.";

my $msg = MIME::Lite->new(
  From     =>'me@myhost.com',
  To       =>'you@yourhost.com',
  Subject  =>'testing',
  Type     =>'multipart/mixed'
);
$msg->attach(
  Type => 'TEXT',
  Data => "$txt"
);
$msg->attach(
  Type        => 'application/pdf',
  Path        => "$srceDir",
  Filename    => "$filename",
  Disposition => 'attachment'
);
$msg->send;
print "Exit ...\n";
exit 0;

Thank you for your help!

 

[lcs01]

I figured out what's wrong in my code.

Wrong:

Path        => "$srceDir",

Should be:

Path        => "$file",

Thanks for reading it.

 

[KevinADC]

stop doing this, quoting single scalars:

"$srceDir"

it's a bad habit to get into

------------------------------------------
- Kevin, perl coder unexceptional!

 

[travs69]

Kevin??
Why is that bad?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those Who Say It Cannot Be Done Are Usually Interrupted by Someone Else Doing It; Give the wrong symptoms, get the wrong solutions;

 

[KevinADC]

it's an invitation for hard to find bugs, and it also creates and unecessary copy of the scalar that never gets used for anything, which just slows down a perl script. The double-quotes are the annonymous string operator, they make a string out of whatever is inside of them. Since the scalar is already defined making another copy is just over-head.

Say you have this:

use strict;
use warnings;
my $foo = 'bar';

then later in the code somehere:

if ("foo" eq 'bar') {
   do something
}

which should have been:

if ($foo eq 'foo') {
   do something
}

but the first example with the '$' ommitted will not return any errors or warnings making it near impossible to find in a large script. The quotation marks around what should have been a scalar ($foo) hide the error completely from all but the human eye. Anyone that thinks they will never make a typo like this just hasn't written enough perl code yet to know better






------------------------------------------
- Kevin, perl coder unexceptional!

 

[travs69]

Thanks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Travis - Those Who Say It Cannot Be Done Are Usually Interrupted by Someone Else Doing It; Give the wrong symptoms, get the wrong solutions;

 

[1DMF]

I except your example Kevin as you are doing a comparison, but the usage Travis had was making a variable = a string.

the two are not comparable.

if you wanted a variable to = a string, you put quotes round it, right?

so

my $var1 = 1;
my $var2 = "$var1";

is ensuring $var2 equals a STRING and not a NUMBER, is this not correct, I also understood in perl that you MUST put double quotes around scalars if you want the scalar to be interpreted first, if you put single quotes round it is would equal the xact text typed not the contents of the scalar.

I know I get language cross over and so my VBA , PERL, HTML etc tend to get mixed up sometimes, so I could be wrong and apprecaite your guidance.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[KevinADC]

I except your example Kevin as you are doing a comparison, but the usage Travis had was making a variable = a string.

I think you mean to say "accept" instead of except"?

the two are not comparable.

They are comparable especially in my concern about introducing hard to find bugs.

if you wanted a variable to = a string, you put quotes round it, right?

No. That is not correct with perl.

so

my $var1 = 1;
my $var2 = "$var1";

is ensuring $var2 equals a STRING and not a NUMBER, is this not correct,

No. Perl will treat $var2 as a string or a number as required by the program. Example:

my $var1 = 1;
my $var2 = "$var1";
my $var3 = $var1;
$var2++;
$var3++;
print $var2 if ($var2 == 2);
print "\n";
print $var2 if ($var2 eq '2');
print "\n";
print $var3 if ($var2 == 2);
print "\n";
print $var3 if ($var2 eq '2');

I also understood in perl that you MUST put double quotes around scalars if you want the scalar to be interpreted first, if you put single quotes round it, [it] would [be] equal [to the e]xact text typed not the contents of the scalar.

In a nutshell: yes. "Interpreted" is not quite correct but your intention is clear. "Interpolation" is the word you are looking for, or "expand". Perl expands scalars (and arrays) inside of double-quoted constructs into their string values. There is no interpolation or expansion of scalars or arrays inside of single-quoted constructs. The only meta character inside of a single-quoted string is the single-quote, which is obviously being used as the end of string terminator.

I know I get language cross over and so my VBA , PERL, HTML etc tend to get mixed up sometimes, so I could be wrong and apprecaite your guidance.

You might be mixing up VBA with perl, I don't know much VBA. But HTML should hopefully not confuse your perl coding.

------------------------------------------
- Kevin, perl coder unexceptional!

 

[1DMF]

thanks Kevin, knew you would help clear that up.

It could be my VBA getting me confused, but also SQL requires quotes for string and not for numbers and will burn if you put quotes around data and try to insert it into an integer defined field.

I beleive all 'basic' also uses quotes to force 'string' converstion so to speak.

but I shall try not to use quotes anymore unles it is actualy containing text and not variables!

As yes your example of hard to find bugs is very true, i've done it myself.

though I do tent to use (.) concatination now as I am heading towards OO design and modules, so find for example $cgi->param('varname'); does not get interpolated even if in double quotes.

regards,
1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[KevinADC]

so find for example $cgi->param('varname'); does not get interpolated even if in double quotes

Thats because it's a reference to a function/method of the $cgi object. It would be the same as expecting this to work:

$foo = 'lizard';
$return = "I am a animal($foo)";
print $return;

sub animal {
   my $type = shift;
   return ('reptile') if $type eq 'lizard';
   return ('unknown species');
}

function calls (code) are not interpreted correctly inside of strings. But you can dereference code inside of double-quoted strings and it will return the correct value:

$foo = 'lizard';
$return = "I am a @{[animal($foo)]}";
print $return;

sub animal {
   my $type = shift;
   return ('reptile') if $type eq 'lizard';
   return ('unknown species');
}

This takes advanatge of the fact that perl interpolates arrays inside of double-quoted strings.

But you should use that convention sparingly. It is still subject to creating hard to find bugs and hard to maintain code.

------------------------------------------
- Kevin, perl coder unexceptional!

 

[1DMF]

a well earned star as always Kevin, thanks


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!