On Sat, 5 Sep 2020 at 10:19, Gregory P. Ennis PoMec@pomec.net wrote:
Stephen and Kenneth,
Thank you very much for your help.
I tried 'MAILRC=/dev/null' which I put in /etc/mail.rc as
'set MAILRC=/dev/null'
No that is meant to be a shell environment variable so that it does not try to read /etc/mail.rc.. if you have it in /etc/mail.rc its not going to help any.
-----------------------------------------------------------------------------------
Stephen,
Unfortunately, the syntax below that I thought was working did not work from a cron job :
"echo | mail -s 'Subject' -r from@address -q /loc/to/body.txt email@address"
Also the addition of environment variables did not work with a cron job. I was not able to get any change in behavior by adding an environment variable as 'MAILRC=/dev.null'. I found an additional reference using the 'MAILRC=/dev/null mailx' and this did not work either.
There was some references of adding additional environment variables which also did not work : 'LC_NAME=fr_FR.UTF-8' 'LC_ALL=fr_FR.UTF-8' The purpose of this as I understood the reference was a faulty interpretation of accents as control characters https://stackoverflow.com/questions/10343106/linux-mail-file-log-has-content...
I finally found two things that worked :
#1. Your reference to the use cat with the -v switch did work with a cron job, and this is the only way I could get mailx to not base64 encode the file.
"cat -v log/logfile.log | mail -s 'here is a log file' 'person@example.com'"
#2. Use of mutt which had the exact same syntax and grammar as mail in 98% of my code
"mutt -s 'Test the dump' Name@domain.com < /u/3/dump"
The easiest fix for me ended up installing mutt and changing the symbolic link of mail->mailx to mail->mutt
I hope this is helpful to others that have the same problem with mailx.
Greg Ennis