We have a ksh script that gets executed daily. It does it function properly however the mail portion does not reflect the subject of the email.
The line of code which executes the mail command is shown below:
mail -s "[Notification]: Success (Date:$batchdate)" `cat $recipients` < $mail_file
Our logs show that the variables batchdate, recipients, and mail_file gets resolved correctly. Now I'm not sure why the subject doesn't show. Is there a different syntax for mail to reflect the subject?
Related
I've been working with Terraform, v0.15.4, for a few weeks now, and have gotten to grips with most of the lingo. I'm currently trying to create a cluster of RHEL 7 instances dynamically on GCP, and have, for the most part, got it to run okay.
I'm at the point of deploying an instance with certain metadata passed along to it for use in scripts built into the machine image for configuration thereafter. This metadata is typically just passed via an echo into a text file, which the scripts then pickup as required.
It's... very simple. Echo "STUFF" > file... Alas, I am hitting the same issue OVER AND OVER and it's driving me INSANE. I've Google'd around for ages, but all I can find is examples of the exact thing that I'm doing, the only difference is that theirs works, mine doesn't... So hopefully I can get some help here.
My 'makes it half-way' code is as follows:
resource "google_compute_instance" "GP_Master_Node" {
...
metadata_startup_script = <<-EOF
echo "hello
you" > /test.txt
echo "help
me" > /test2.txt
EOF
Now the instance with this does create successfully, although when I look onto the instance, I get one file called ' /test.txt? ' (or if I 'ls' the file, it shows as ' /test.txt^M ') and no second file.. I can run any command instead of echo, and whilst the first finishes, the second+ does not. Why?? What on earth is causing that??
The following code I found also, but it doesn't work for me at all, with the error, 'Blocks of type "metadata" are not expected here.'
resource "google_compute_instance" "GP_Master_Node" {
...
metadata {
startup-script = "echo test > /test.txt"
}
Okaaaaay! Simple answer for a, in hindsight, silly question (sort of). The file was somehow formmated in DOS, meaning the script required a line continuation character to run correctly (specifically \ at the end of each individual command). Code as follows:
resource "google_compute_instance" "GP_Master_Node" {
...
metadata_startup_script = <<-EOF
echo "hello
you" > /test.txt \
echo "help
me" > /test2.txt \
echo "example1" > /test3.txt \
echo "and so on..." > /final.txt
EOF
However, what also fixed my issue was just 'refreshing' the file (probably a word for this, I don't know). I created a brand new file using touch, 'more'd the original file contents to screen, and then copy pasted them into the new one. On save, it is no longer DOS, as expected, and then when I run terraform the code runs as expected without requiring the line continuation characters at the end of commands.
Thank you to commentors for the help :)
From linux, I send this file to an outlook account...
<html>
<h2>HELLO</h2>
</html>
It appears just as you see, plain text.
How can I get this to display on Outlook as it appears when I run it through firefox on liunux ?
In linux, I sent it as plain test using a system call in a perl script....
mail -s 'the title' 'recipient' < the_file.html.
'which mail' eventually ends up being mailx
The thinking is that outlook would recognize the "html" (between the < and > which won't display here) as line 1 and do the right thing.
You need to set the correct ContentType in the header.
e.g.:
Content-Type: text/html; charset=UTF-8
Here is an old example in Perl that might help you:
How can I send an HTML email with Perl?
As it turns out, we also had "mutt" installed and I was able to use that.
E.g.
my $cmd = "mutt -e 'set content_type=text/html' -s '${title}' '${to_list}' < ${email_file}"
my $stat = system($cmd);
I made a very small app for the raspberry pi, that uses Sinatra:
https://github.com/khebbie/SpeakPi
The app lets the user input some text in a textarea and asks Google to create an mp3 file for it.
In there I have a shell script called speech2.sh which calls Google and plays the mp3 file:
#!/bin/bash
say() {
wget -q -U Mozilla -O out.mp3 "http://translate.google.com/translate_tts?tl=da&q=$*";
local IFS=+;omxplayer out.mp3;
}
say $*
When I call speech.sh from the commandline like so:
./speech2.sh %C3%A6sel
It pronounces %C3%A6 like the danish letter 'æ', which is correct!
I call speech2.sh from a Sinatra route like so:
post '/say' do
message = params[:body]
system('/home/pi/speech2.sh '+ message)
haml :index
end
And when I do so Google pronounces some very weird chars like 'a broken pipe...' which is wrong!
All chars a-z are pronounced correctly
I have tried some URL encoding and decoding, nothing worked.
I tried outputting the message to the command-line and it was exactly "%C3%A6" that certainly did not make sense.
Do you have any idea what I am doing wrong?
EDIT
To Sum it up and simplify - if I type like so in bash:
./speech2.sh %C3%A6sel
It works
If I start an irb session and type:
system('/home/pi/speech2.sh', '%C3%A6sel')
It does not work!
Since it is handling UTF-8, make sure that the encoding remains right the way through the process by adding the # encoding: UTF-8 magic comment at the top of the Ruby script and passing the ie=UTF-8 parameter in the query string when calling Google Translate.
I have some perl scripts which are scheduled using task scheduler in windows 2003 R2 and 2008. These scripts are called directly using perl.exe or via a batch file.
Sometimes these scripts fails to execute (crashes maybe) and we are not aware of these crashes.
Are there any ways a mail can be sent when these script crashes? more or less like monitoring of these scripts
Thanks in advance
Karthik
Why monitor the scripts from the outside when you can make the plugins to monitor theirself? First you can use eval in order to catch errors, and if an error occours you can send an email with the Net::SMTP module as rpg suggested. However I highly recommend you to use some kind of log file in order to keep trace of what happened right before the error and what caused the error. Your main goal should be to avoid the error. That ofcourse requires you to modify the scripts, if, for any reason, you cannot do that then the situation may be a little more complicated because you need another script.
With the Win32::Process::Info module you can retrieve running processes on Windows and check if your plugin is running or not.
while(1) {
my $found = false;
my $p = Win32::Process::Info->new;
foreach my $proc ($pi->GetProcInfo) {
if ($proc->{Name} =~ /yourscriptname/i ) {
found = true;
}
}
if ($found eq 'false') {
# send email
my $smtp = Net::SMTP->new("yoursmtpserver");
eval {
$smtp->mail("sender#test.it");
$smtp->recipient("recipient#test.it");
$smtp->data;
$smtp->datasend("From: sender#test.it");
$smtp->datasend("\n");
$smtp->datasend("To: recipient#test.it");
$smtp->datasend("\n");
$smtp->datasend("Subject: Plugin crashed!");
$smtp->datasend("\n");
$smtp->datasend("Plugin crashed!");
$smtp->dataend;
$smtp->quit;
};
}
sleep(300);
}
I did not test this code because I don't have Perl installed on Windows but the logic should be ok.
For monitoring - Please check the error code. This will help you for its failure.
For mail sending - You can use Net::SMTP module to send email. Let me know if you need a code snippet for it.
You can use PushMon to monitor your scripts. What you do is create PushMon URLs that matches the schedule of your Perl scripts. Then you should "ping" these URLs when your scripts run successfully. If these URLs are not accessed, maybe because your scripts crashed or there's a power failure, PushMon will notify you by email.
Disclaimer: I am associated with PushMon.
I created a small shell script which logs all of it's input to a log file, with which I had thought I could replace the sendmail binary and thus achieve a simple way to simulate e-mail delivery without actually setting up a working sendmail.
This failed, however. For reasons I cannot understand.
I've looked at the PHP mail.c source and as far as I can understand (mind you, I'm not very experienced in C), PHP executes and talks directly to the binary (set in sendmail_path). But no log files are being created when I replace the sendmail binary with my script and the script replacing sendmail will always create a log file when it's executed, regardless of if there's input present or not.
The script itself works fine. Its' return codes should conform to that of sendmail's. With the difference that my script always returns 0, regardless of the input, since I'm not really interested in checking if the input is valid - just that I'm getting some.
Is it possible to achieve what I want, i.e. using a sendmail simulator?
The script source is provided below:
#!/bin/bash
LOGDIR=/tmp/sendmail-sim
NOW=$(date +%Y%m%dT%H%M)
CNT=1
FILENAME="$LOGDIR/$NOW.$CNT.log"
while [ -f $FILENAME ]; do
CNT=$(($CNT + 1))
FILENAME="$LOGDIR/$NOW.$CNT.log"
done
echo "$0 $*" > $FILENAME
while read BUF
do
echo $BUF >> $FILENAME
done
exit 0
PS. My current sendmail (or actually, postfix) does receive email from PHP, but I don't want to actually send any email or need to go digging in its' mail queue in development.
The problem was User Error, as usually. So, boys and girls, don't forget to check write permissions on all the relevant folders.
I've used Fakemail for this purpose in the past. It accepts SMTP connections but writes all mail to files rather than sending them along as email. There are both python and perl implementations.
http://www.lastcraft.com/fakemail.php
We setup apache to serve the directory that Fakemail was writing to. That was a quick and easy way for staff to view the messages that Fakemail was receiving and review for content, destination, etc. Formatting of HTML emails was a bit whacky for various reasons, so it was not so useful for vetting formatting of html emails.
If you need to to test you PHP application's ability to properly format and send email without actually sending them, I suggest you use the Pear Mail package. Fiddling with your system is not a good idea.
If you use Mail from Pear you could switch from sendmail to smtp to a mock implementation of the mail interface by changing the driver from 'sendmail' or 'smtp' to 'mock'.
http://pear.php.net/package/Mail/docs/latest/Mail/Mail.html
http://pear.php.net/package/Mail/docs/latest/Mail/Mail_mock.html
If your code looks like this:
mail('me#example.com', 'My Subject', $message);
Then change it to be testable using PEAR Mail:
include('Mail.php');
function sendEmail($recipient, $subject, $body, $driver = 'mail') {
$m = Mail::factory("mail");
$headers = array(
"From"=>"me#example.com",
"To" => $recipient,
"Subject"=> $subject);
$m->send($recipient, $headers, $body);
return $m;
}
// In Production:
sendEmail('me#example.com', 'My Subject', $message);
// During testing:
$m = sendEmail('me#example.com', 'My Subject', $message, 'mock');
var_dump($m->sentMessages);
This is very crude, since you should be using PHPUnit or SimpleTest, but this is a topic for another time and place :)
A note, if you just want to grab stdin and write it into a file, you don't need to loop one line at a time: you can write
cat - >> $FILENAME