Linux 使用 crontab 作业发送邮件，邮件正文变成一个名为 ATT00001.bin 的附件
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18999690/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Use crontab job send mail, The email text turns to an attached file which named ATT00001.bin
提问by Alex
I want to analysis some data in one linux server,then send the it as Email text to my Email account , But when i execute this shell scripts in shell command, It works well, Weird is that when i put all the procedure into crontab job, The Email text will turns to an attached file, Can someone help?
我想在一台 linux 服务器中分析一些数据，然后将其作为电子邮件文本发送到我的电子邮件帐户，但是当我在 shell 命令中执行此 shell 脚本时，它运行良好，奇怪的是当我将所有程序放入 crontab 作业时, 电子邮件文本将变成附件，有人可以帮忙吗？
#* * * * * sh -x /opt/bin/exec.sh >> /opt/bin/mailerror 2>&1
/* exec.sh */
#/bin/sh
cd /opt/bin
./analysis.sh > test
mail -s "Today's Weather" [email protected] < test
But when i execute exec.sh in shell command line directly, The Email will get text, Can someone explain it for me, grate thanks.
但是当我直接在 shell 命令行中执行 exec.sh 时，电子邮件会收到文本，有人可以为我解释一下，谢谢。
回答by SriniV
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.
您的脚本假定它是从特定目录运行的（请注意，几乎每个路径都是相对路径，而不是绝对路径）。cron 恰好从另一个目录运行它。
The Fix for text appearing on email
修复电子邮件中出现的文本
mydir=$(dirname "./opt/bin/analysis.sh > test
mail -s "Today's Weather" [email protected] < /opt/bin/test
") && cd "${mydir}" || exit 1
./opt/bin/analysis.sh > test
mail -s "Today's Weather" [email protected] < /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.
$0 是正在执行的 shell 脚本的（可能是相对的）文件名。给定文件名，dirname 命令返回包含文件名的目录。因此，该行将目录更改为包含脚本的目录，或者如果 dirname 或 cd 失败则退出并显示错误代码。
OR try to have full path like
或尝试使用完整路径，例如
crontab -l > oldcrontab
cp oldcrontab newcrontab
echo "$newline" >> newcrontab
crontab < newcrontab
Note: The same problem is discussed earlier here
注意：这里之前讨论过同样的问题
FOLLOW UP:
跟进：
Try to remove
尝试删除
sh -x /opt/bin/exec.sh >> /opt/bin/mailerror 2>&1
sh -x /opt/bin/exec.sh >> /opt/bin/mailerror 2>&1
and instead use
而是使用
sh /opt/bin/exec.sh 2>&1 >> /opt/bin/mailerror
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 命令编辑文件，则必须重新启动 cron 以使更改生效。
echo "$Output" | /usr/bin/tr -cd '-6' | mail ...
回答by sastorsl
Ran into the same problem myself, only I'm piping text output into mailx- Heirloom mailx 12.4 7/29/08
我自己也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 crontabthe body of the email came as an attachment - ATT00001.BIN (Outlook), application/octet-stream (mutt) or "noname" (Gmail).
在命令行上运行脚本时，电子邮件作为带有文本正文的普通电子邮件出现。
但是，当我通过crontab电子邮件正文运行完全相同的脚本时，它以附件形式出现 - ATT00001.BIN (Outlook)、application/octet-stream (mutt) 或 "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.
Mailx 会，如果它在文本输入中遇到未知/控制字符，将其转换为带有 application/octet-stream mime-type 集的附件。
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
所以你需要删除那些控制字符，这可以用 ie 来完成 tr
LANG="en_US.UTF8" ; export LANG
However since I had Norwegian UTF8 characters: ??? - the list expand, and you don't really want to maintain such a list, and I needthe norwegian characters.
但是，由于我有挪威语 UTF8 字符：??? - 列表扩展了，你真的不想维护这样的列表，我需要挪威字符。
And inspecting the attachment I found I had only \r, \n the "regular" ASCII characters in range 32-176 - all printable and184 and 195 --> UTF8
并检查附件，我发现我只有 \r,\n 范围 32-176 中的“常规”ASCII 字符 - 所有可打印以及184 和 195 --> UTF8
Sollution
解决方案
Explicitly set the locale in your script:
在脚本中显式设置语言环境：
cat logfile | tr -d \r | mailx -s'the logfile' to-me@.....
Run exportin your shell - or setenvif you run cshor tcshto determine what your locale is set to.
export在您的 shell 中运行- 或者setenv如果您运行csh或tcsh确定您的语言环境设置为什么。
Explanation
解释
Mailx - when run in your shell - with LANG set to .UTF8, will correctly identify the UTF8 chars and continue.
Mailx - 在 shell 中运行时 - LANG 设置为 .UTF8，将正确识别 UTF8 字符并继续。
When run in crontabLANG is not set, and default to LANG=C, since by default crontab will run only a restricted set of environment variables (system dependant).
crontab未设置在LANG 中运行时，默认为 LANG=C，因为默认情况下 crontab 将仅运行一组受限制的环境变量（取决于系统）。
mailx (or other programs) will then notrecognize UTF8 characters and determine that the input containes unknown control characters.
mailx（或其他程序）将无法识别 UTF8 字符并确定输入包含未知控制字符。
My issue was UTF8 characters, yours could be other control characters in your input. Run it through hexdumpor od -c, but since it works OK in a regular shell I'm suspecting LANG issues.
我的问题是 UTF8 字符，您的问题可能是输入中的其他控制字符。通过hexdumpor运行它od -c，但由于它在常规 shell 中工作正常，我怀疑 LANG 问题。
References:
参考：
回答by adivis12
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:
我有同样的问题，以上都没有解决问题。移动文件中的额外回报为我解决了这个问题：
##代码##Thanks to this forum:
感谢本论坛：
https://forums.opensuse.org/showthread.php/445955-mailx-creates-unwanted-attachment
https://forums.opensuse.org/showthread.php/445955-mailx-creates-unwanted-attachment
