perl variables from open file doesn't work - perl

i need some help with a sendmail perl script.
So i have 1 part of html message included from file msg.txt and second part is already in my $html
I have 2 variables into msg.txt(first part) that doesn't work.. in the second part it works fine..
EDIT : So . in the msg.txt file i have the following : $website,$token that is declared in perl script. When i run the script i receive email containing names of variables($token,$website) instead value of variables..
CODE
$website = "domain.com";
$token = 'token123456';
open(IN,$list);
while(chop($email_line=<IN>)) {
local $/ = undef;
open MSG, "msg.txt";
$msg = <MSG>;
close FILE;
my #html = "
<html>
$msg (!!! variables $website and $token doesn't work in $msg !!!)
<div style='margin-top:5px; text-align: center;>
Website : $site | Token : $token ( variables are working)
</div>
</html>
";
}
OUTPUT
// this is first part
Website : $website | Token : $token
//this is second part that works
Website : domain.com | Token : token12345

You interpolate the contents of $msg into #html (which should probably be a scalar variable, not an array) and then you expect the Perl compiler to automatically run another level of interpolation to expand the variables that were in $msg and are now in $html. And Perl simply doesn't work like that. It only does a single level of interpolation without you jumping through a few hoops in order to tell it what you want it to do.
If you want to be a successful Perl programmer, then I highly recommend taking a few hours to read through the Perl FAQ. It will make your Perl programming life easier and more productive.
In particular, it includes this question and answer:
How can I expand variables in text strings?
The answer shows a complex method using a double /ee flag on a substitution operator, but it also gives the correct answer which is "use a templating system".

Related

Perl Mail::Mailer not working

I'm new to using modules in Perl. My head is exploding right now and i would like to know what is wrong in here:
#!/usr/bin/perl
use strict;
use Mail::Mailer;
my $from_adress = "email\#xxxxx.com";
my $to_adress = "email\#hxxxx.com";
my $subject = "There goes bananas\n";
my $body = "Here is the bananas";
my $server = "smtp.gmail.com";
my $mailer = Mail::Mailer->new("smtp", Server => $server);
$mailer->open({
From => $from_adress,
To => $to_adress,
Subject => $subject,
});
print $mailer $body;
$mailer->close();
open(F, '>>', $Mail::Mailer::testfile::config{outfile});
print F #_;
print #_;
close (F);
Sorry to post the whole script but i'm not sure where it went wrong. I don't get any print from #_ variable. I would love to receive advises on how to improve in using modules in Perl and how i can get better at it.
Thanks in advance.
Well done for using strict in your code. For extra credit, add a use warnings line too.
I can't see any obvious problems with the way you're using the module. Do you think there's something wrong? Is the email not being sent?
If you're not getting the email, then I'd suggest that your first step should be to follow the example in the documentation and change the close line to:
$mailer->close
or die "couldn't send whole message: $!\n";
I wonder if the problem (if there is one) is that you're using Google's SMTP server and you don't have permission to do that. Perhaps you need to authenticate first.
A few other points about your code.
There is no need for all of your set-up variables to be initialised with double-quoted strings. And if you switch to single-quoted strings then you no longer need to escape the #s in the data. You would need double quotes to put the newline in $subject, but I've removed that as email subject lines rarely contain newlines.
my $from_adress = 'email#xxxxx.com';
my $to_adress = 'email#hxxxx.com';
my $subject = 'There goes bananas';
my $body = 'Here is the bananas';
my $server = 'smtp.gmail.com';
The last four lines of your code are confusing in many ways. I'm not really sure what you're trying to achieve there. I'll point out two things though. Firstly, we generally use lexical filehandles these days. If you're learning from a source that uses bareword filehandles, then I'd worry slightly about its age. So the file opening line should look like this:
# $f is, of course, a terrible name for a variable
open(my $f, '>>', $Mail::Mailer::testfile::config{outfile});
You are then printing the value of #_. In Perl, #_ contains the arguments to a subroutine. And this code isn't inside a subroutine, so #_ will be empty. So I'm not surprised that you're not getting any output.
Lastly, I'll point out that I find that I enjoy working with email in Perl a lot more when I'm using tools from the Email::* namespace. In particular, I'd use Email::Sender for sending email.
Update: Ok, I've had a closer look at the Mail::Mailer documentation and I think I understand what you're trying to do in the last four lines. I think you're trying to write the mail message data to the file. Is that right?
If it is, then you're misunderstanding the documentation. The way to do that is to change the type that you pass to new(). It needs to be testfile rather than smtp. So change
my $mailer = Mail::Mailer->new("smtp", Server => $server);
to
my $mailer = Mail::Mailer->new("testfile",);
That will write the mail to a file called mailer.testfile and no mail will be sent.

Grep command to find blank line - works in terminal, not in the file itself?

I am writing a perl script, called by qmail for each incoming mail, to parse the content and find the body of the email. The reason for doing so is to add some user information from a database, append that to the body, and forward to another address (a listserv).
Unsolveable problem is this:
cat dbody.txt|grep -A1000 '^\s*$'
Purpose: To find the first blank line (being the end of header information) and return all after that
When I run that line from the command line (using terminal) (ie. directly) - it works fine. Returns the body of the email.
When I run it in the script itself - it doesn't.
Have tested endlessly and cannot think of a reason as to why this would be, or what I should change. help!
Lines from the script - the first "test" - works fine.
$test =`cat dbody.txt|grep -A1000 '^\s*$'`;
$body= `cat dbody.txt|grep -A1000 '2,/^$/d'`;
When I print the above into the final email - $test returns the full text (as a test), $body remains blank.
You can use Perl like this:
use strict;
use warnings;
my $body;
open my $file, "<", "dbody.txt" or die("$!");
while (<$file>) {
$body .= $_ if defined $body;
$body = "" if not defined $body and /^$/;
}
close $file;
print $body;
or, escape the dollar signs:
$body= `grep -A1000 '2,/^\$/d' dbody.txt`;
The standard solution in sed:
sed '1,/^$/d' dbody.txt
In other words, delete through the first empty line.
Note that your regex was wrong, too, albeit harmless in practice. The separator line must not even contain any whitespace (but I don't think you will ever find a real-life email message with a whitespace-only header line).

Issue with "#" in perl scripting

I am developing an automation script in perl in which for authentication I have written a subroutine which takes password input by user and return it to the main perl program which in turn passes the password to the tool that I need to automate.
This script goes fine with every case unless the character # is part of the password. Then it is not able to automate the tool and fails for authentication.
Below is the subroutine which I used for taking password input.
use Win32::Console;
sub password() {
$StdIn = new Win32::Console(STD_INPUT_HANDLE);
my $Password = "";
$StdIn->Mode(ENABLE_PROCESSED_INPUT);
print "Enter Password: ";
while (ord(my $Data = $StdIn->InputChar(1)) != 10) {
if("\r" eq $Data ) {
last;
}
elsif ("\ch" eq $Data) {
if( "" ne chop( $Password )) {
print "\ch \ch";
}
next;
}
$Password .=$Data;
print "*";
}
return $Password;
}
i am calling the above subroutine as
$passwd = &password();
And then passing the $passwd to the tool that I need to automate as below,
This is the line in which I pass the password to tool,
cc -c URL OF THE TOOL:$server -d $domain -t $appl -u $userid -p $passwd; \n";
Can anyone please cross check the code for calling the password() sub routine, returning $password and passing $passwd to the tool. I think error may be at one of the three places.Someone please help and if possible provide the code too.
You are probably passing the user input to an external tool of some sort that doesn't support literal #, perhaps because it is interpreted as "start of comment". The shell is a likely suspect. But without sample code, it is impossible for us to be sure what your problem is.
It seems to me like issue with quoting on the shell side. Proper quoting rules are entirely dependent on your system's command shell. In bash, for example, you can often be fairly safe with something like -p '$password', while transliterating ' to \' in the Perl script. Or there could be a module for that, of which I'm not aware.
However, it's the "cc" thing you're passing data into. The tool could could support easier way to safely pass the password, i.e. avoid the need of quoting arbitrary data. Examples of such facilities are via STDIN, via external file (well that could be actually pretty unsafe :)) or as a null-terminated string. Or passing the hash only. So I'd look into the documentation.
Be aware that by passing user collected data into shell, you're posing a great security risk. Consider using Perl's Taint mode.
Update: You say it's Windows, so I should warn you: quoting for cmd.exe is one of the most complicated, painful and frustrating things I've ever done. Have a look at this question

Is there a CPAN module to extract the current level of content from an email

I'm looking for a module to do a best-effort attempt to extract the immediate level of content (ie discarding any quoted content and the signature block) from the plain text component of an email.
We've already got some code that has a shot at it, so if there is no existing module that does it, ideas for a name for a new module would also be appreciated (Text::ExtractImmediateLevelOfContentFromEmail seems a bit unwieldy).
I believe there's no such module because that's very task oriented and there's a huge variety of message formatting styles. The minimal implementation is something you can do with a few lines of code:
use Email::MIME;
my $email = Email::MIME->new($message);
my $body;
$email->walk_parts(sub {
my ($part) = #_;
return unless $part->content_type =~ m[text/plain];
$body .= $part->body;
});
# strip quoted lines and attribution line
$body =~ s/^.+ wrote:\n(?=\n* ?>)//m;
$body =~ s/^ ?>.*\n//gm;
# strip signature
$body =~ s/-- \R.+//;
Of course you may want to add other heuristic rules to remove attribution lines written in other languages, as well as removing Outlook-style quoted text.
I'd suggest some heuristics to avoid quoted text stripping if the message is recognized to use interleaved-style quoting. That's because interleaved replies may loose some meaning if you strip quoted text.
If you want to factor that out to a module, I'd call it Email::ExtractBody or Email::ExtractText. I'd stress in the POD that the module has a heuristic and best-effort approach.

Is it possible to send POST parameters to a CGI script without another HTTP request?

I'm attempting to run a CGI script in the current environment from another Perl module. All works well using standard systems calls for GET requests. POST is fine too, until the parameter list gets too long, then they get cut off.
Has anyone ran in to this problem, or have any suggestions for other ways to attempt this?
The following are somewhat simplified for clarity. There is more error checking, etc.
For GET requests and POST requests w/o parameters, I do the following:
# $query is a CGI object.
my $perl = $^X;
my $cgi = $cgi_script_location; # /path/file.cgi
system {$perl} $cgi;
Parameters are passed through the
QUERY_STRING environment variable.
STDOUT is captured by the calling
script so whatever the CGI script
prints behaves as normal.
This part works.
For POST requests with parameters the following works, but seemingly limits my available query length:
# $query is a CGI object.
my $perl = $^X;
my $cgi = $cgi_script_location; # /path/file.cgi
# Gather parameters into a URL-escaped string suitable
# to pass to a CGI script ran from the command line.
# Null characters are handled properly.
# e.g., param1=This%20is%20a%20string&param2=42&... etc.
# This works.
my $param_string = $self->get_current_param_string();
# Various ways to do this, but system() doesn't pass any
# parameters (different question).
# Using qx// and printing the return value works as well.
open(my $cgi_pipe, "|$perl $cgi");
print {$cgi_pipe} $param_string;
close($cgi_pipe);
This method works for short parameter lists, but if the entire command gets to be close to 1000 characters, the parameter list is cut short. This is why I attempted to save the parameters to a file; to avoid shell limitations.
If I dump the parameter list from the executed CGI script I get something like the following:
param1=blah
... a bunch of other parameters ...
paramN=whatever
p <-- cut off after 'p'. There are more parameters.
Other things I've done that didn't help or work
Followed the CGI troubleshooting guide
Saved the parameters to a file using CGI->save(), passing that file to the CGI script. Only the first parameter is read using this method.
$> perl index.cgi < temp-param-file
Saved $param_string to a file, passing that file to the CGI script just like above. Same limitations as passing the commands through the command line; still gets cut off.
Made sure $CGI::POST_MAX is acceptably high (it's -1).
Made sure the CGI's command-line processing was working. (:no_debug is not set)
Ran the CGI from the command line with the same parameters. This works.
Leads
Obviously, this seems like a character limit of the shell Perl is using to execute the command, but it wasn't resolved by passing the parameters through a file.
Passign parameters to system as a single string, from HTTP input, is extremely dangerous.
From perldoc -f system,
If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is /bin/sh -c on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument,..
In other words, if I pass in arguments -e printf("working..."); rm -rf /; I can delete information from your disk (everything if your web server is running as root). If you choose to do this, make sure you call system("perl", #cgi) instead.
The argument length issue you're running into may be an OS limitation (described at http://www.in-ulm.de/~mascheck/various/argmax/):
There are different ways to learn the upper limit:
command: getconf ARG_MAX
system header: ARG_MAX in e.g. <[sys/]limits.h>
Saving to a temp file is risky: multiple calls to the CGI might save to the same file, creating a race condition where one user's parameters might be used by another user's process.
You might try opening a file handle to the process and passing arguments as standard input, instead. open my $perl, '|', 'perl' or die; fprintf(PERL, #cgi);
I didn't want to do this, but I've gone with the most direct approach and it works. I'm tricking the environment to think the request method is GET so that the called CGI script will read its input from the QUERY_STRING environment variable it expects. Like so:
$ENV{'QUERY_STRING'} = $long_parameter_string . '&' . $ENV{'QUERY_STRING'};
$ENV{'REQUEST_METHOD'} = 'GET';
system {$perl_exec} $cgi_script;
I'm worried about potential problems this may cause, but I can't think of what this would harm, and it works well so far. But, because I'm worried, I thought I'd ask the horde if they saw any potential problems:
Are there any problems handling a POST request as a GET request on the server
I'll save marking this as the official answer until people have confirmed or at least debated it on the above post.
Turns out that the problem is actually related to the difference in Content-Length between the original parameters and the parameter string I cobbled together. I didn't realize that the CGI module was using this value from the original headers as the limit to how much input to read (makes sense!). Apparently the extra escaping I was doing was adding some characters.
My solution's trick is simply to piece together the parameter string I'll be passing and modify the environment variable the CGI module will check to determine the content length to be equal to the .
Here's the final working code:
use CGI::Util qw(escape);
my $params;
foreach my $param (sort $query->param) {
my $escaped_param = escape($param);
foreach my $value ($query->param($param)) {
$params .= "$escaped_param=" . escape("$value") . "&";
}
}
foreach (keys %{$query->{'.fieldnames'}}) {
$params .= ".cgifields=" . escape("$_") . "&";
}
# This is the trick.
$ENV{'CONTENT_LENGTH'} = length($params);
open(my $cgi_pipe, "| $perl $cgi_script") || die("Cannot fork CGI: $!");
local $SIG{PIPE} = sub { warn "spooler pipe broke" };
print {$cgi_pipe} $params;
warn("param chars: " . length($params));
close($cgi_pipe) || warn "Error: CGI exited with value $?";
Thanks for all the help!