Use crontab job send mail, The email text turns to an attached file which named ATT00001.bin

Ran into the same problem myself, only I'm piping text output into mailx - Heirloom mailx 12.4 7/29/08

When running the script on the command line the email came out as normal email with a text body.
However, when I ran the exact same script via crontab the body of the email came as an attachment - ATT00001.BIN (Outlook), application/octet-stream (mutt) or "noname" (Gmail).

Took some research to figure this out, but here goes:

Problem

Mailx will, if it encounters unknown / control characters in text input, convert it into an attachment with application/octet-stream mime-type set.

From the man page:

for any file that contains formatting characters other than newlines and horizontal tabulators

So you need to remove those control characters, which can be done with i.e. tr

echo "$Output" | /usr/bin/tr -cd '\11\12\15\40-\176' | mail ...

However since I had Norwegian UTF8 characters: æøå - the list expand, and you don't really want to maintain such a list, and I need the norwegian characters.

And inspecting the attachment I found I had only \r, \n the "regular" ASCII characters in range 32-176 - all printable and 184 and 195 --> UTF8

Sollution

Explicitly set the locale in your script:

LANG="en_US.UTF8" ; export LANG

Run export in your shell - or setenv if you run csh or tcsh to determine what your locale is set to.

Explanation

Mailx - when run in your shell - with LANG set to .UTF8, will correctly identify the UTF8 chars and continue.

When run in crontab LANG is not set, and default to LANG=C, since by default crontab will run only a restricted set of environment variables (system dependant).

mailx (or other programs) will then not recognize UTF8 characters and determine that the input containes unknown control characters.

My issue was UTF8 characters, yours could be other control characters in your input. Run it through hexdump or od -c, but since it works OK in a regular shell I'm suspecting LANG issues.

References:

• linux mail < file.log has Content-Type: application/octet-stream (a noname attachment in Gmail)
• http://alvinalexander.com/blog/post/linux-unix/how-remove-non-printable-ascii-characters-file-unix

I had this same issue and none of the above fixed the problem. Moving the extra return in the file fixed the issue for me:

cat logfile | tr -d \\r | mailx -s'the logfile' to-me@.....

Thanks to this forum:

https://forums.opensuse.org/showthread.php/445955-mailx-creates-unwanted-attachment

Make sure you change this in your script

#/bin/sh

to be replaced by

#!/bin/sh

Coming to the problem

Your script assumes that it is being run from a particular directory (note that almost every path is a relative path, not an absolute path). cron happens to be running it from another directory.

The Fix for text appearing on email

mydir=$(dirname "$0") && cd "${mydir}" || exit 1./opt/bin/analysis.sh > test mail -s "Today's Weather" example@example.com < /opt/bin/test

Explanation

$0 is the (possibly relative) filename of the shell script being executed. Given a filename, the dirname command returns the directory containing the filename. So, that line changes directories to the directory containing the script or exits with an error code if either dirname or cd fails.

OR try to have full path like

./opt/bin/analysis.sh > test mail -s "Today's Weather" example@example.com < /opt/bin/test

Note: The same problem is discussed earlier here

FOLLOW UP:

Try to remove

sh -x /opt/bin/exec.sh >> /opt/bin/mailerror 2>&1

and instead use

sh /opt/bin/exec.sh 2>&1 >> /opt/bin/mailerror

FOLLOW UP

You have to restart cron for changes to take effect if you do not use the crontab command to edit the file.

crontab -l > oldcrontabcp oldcrontab newcrontabecho "$newline" >> newcrontabcrontab < newcrontab