Score:1

'mail' not working in Script same way it is working from command line

mf flag

The below line of code/command is working as expected if I run it from Unix terminal, but not if I include it in a script and run the script - exact same.

I am expecting the X-Priority to show the mail as high priority in Outlook. If I run it from command line, I see the email is showing correctly as high priority and I see the file is attached and the body appear as supposed to. However, if I write it a shell script and run the script, the mail come formatted as text and attachment is appended to the body of the email and the email is shown as normal in outlook.

Not sure what I am doing wrong. Any help is appreciated.

Shell Script

#!/bin/sh
echo "Message Body" | mail -r "[email protected]" -c "[email protected]" -s "$(echo -e "Message Subject\nX-Priority: 1")" -a "logFile.log" "[email protected]"

Also tested with Shell Script

#!/bin/bash
echo "Message Body" | /usr/bin/mail -r "[email protected]" -c "[email protected]" -s "$(echo -e "Message Subject\nX-Priority: 1")" -a "logFile.log" "[email protected]"

Command line

echo "Message Body" | mail -r "[email protected]" -c "[email protected]" -s "$(echo -e "Message Subject\nX-Priority: 1")" -a "logFile.log" "[email protected]"

EDIT: More Details/Observation on further R&D:

In Subject, in my actual command, there is a variable assignment like MyApp : ${HostName} : Restarted\nX-Priority: 1. HostName is a variable i defined in the script. If I replace the variable hard-coded value like MyApp : myserver : Restarted\nX-Priority: 1, the command line and script behave the exact same. If I keep the variable in command line, it works as expected (the X-Priority part) but the subject comes as MyApp : : Restarted as expected as the variable is not defined.

I tried to add an undefined variable in script and it still did not work.

Hope this gives more insights into the issue.


Note: I originally asked this question in stackoverflow. But I was advised to ask it here instead - https://stackoverflow.com/questions/75585298/mail-not-working-in-script-same-way-it-is-working-from-command-line

--

ccc_cdxxb avatar
pl flag
Are the shells the same? You have your script as /bin/sh but what is your command line using? ksh, bash, and sh will sometimes behave differently for certain utilities/commands in my experience.
akpuvvada avatar
mf flag
I tested with both sh and bash - my terminal is using bash by default. Getting same output in both.
Phill  W. avatar
cn flag
If your terminal is normally bash then why write scripts in anything else? "#! /bin/bash" keeps everything on a level playing field. Just to rule out a fairly obvious suspect here - just how are you running this "script" of yours? Interactively, in the terminal, yes? Not through, say, *cron*?
akpuvvada avatar
mf flag
@PhillW., sorry I was not clear. I tried with both scripts - with bash and with sh - I just posted the latest script I was working on. Both gave the same output.
ws flag
Get the path of the mail command from your shell with "which mail", also check the output of "alias mail". Substitute the explicit value in your shell script, re-test and avise on whether this had any impact.
akpuvvada avatar
mf flag
Below is the output of the commands. [root@myserver ~]$ which mail /usr/bin/mail [root@myserver ~]$ alias mail -bash: alias: mail: not found [root@myserver ~]$
akpuvvada avatar
mf flag
Updated the script with that and still getting the same outcome.
Score:0
ma flag

What OS/Distro are you using?

Many distros are commonly using BSD mailx as an alias to the mail command, but then there might be an alternate or when your script runs, it has a different PATH and therefore uses a different program to the one you expect. (As perhaps your OS has some other ideas for what mail for users should do.)

Try from your terminal:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Then the same in your script to see if there's something different about the PATHS

BSD mailx will be in somewhere like /usr/bin/mailx

It looks like it has different options to whatever mail command you are using, though. (See man mailx / man mail). Are you trying to get:

Subject: Message Subject 
  X-Priority: 1

Or the subject, then an additional header:

Subject: Message Subject
X-Priority: 1

bash will strip newlines from variables if you try to use them like that to invoke another command.

If it's mailx:

  • -a Specify additional header fields on the command line such as "X-Loop: foo@bar" etc.

I'd try something like:

#!/bin/bash
echo "Message Body" | /usr/bin/mailx -a "X-Priority: 1" -s "Message Subject" -r [email protected] -c [email protected] -- [email protected]

I don't think there is an (easy) way to get the stock mail/mailx to add attachments, though. It's not a thing it can do.

You could use an alternative like mutt or neomutt:

options:

  --            Special argument forces NeoMutt to stop option parsing and treat
                remaining arguments as addresses even if they start with a dash

  -a <file>     Attach one or more files to a message (must be the last option)
                Add any addresses after the '--' argument

  -c <address>  Specify a carbon copy (Cc) recipient

  -s <subject>  Specify a subject (must be enclosed in quotes if it has spaces)


Sounds like it will do more like what you want anyway.

echo "Message Body" | mutt -s "Message Subject" \ 
-e "my_hdr X-Priority: 1" \
-e "my_hdr From: [email protected]" \ 
-c [email protected] \
-a /path/to/logFile.log \
-- [email protected]


echo "Message Body" | mutt -s "Message Subject" -e "my_hdr X-Priority: 1" -e "my_hdr From: [email protected]" -c [email protected] -a /path/to/logFile.log -- [email protected]
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.