如何阻止 crontab 弄乱这个简单的 BASH 脚本（以及为什么会这样）？答案

【问题标题】：How can I stop crontab from messing up this simple BASH script (and why is it happening)?如何阻止 crontab 弄乱这个简单的 BASH 脚本（以及为什么会这样）？
【发布时间】：2010-08-25 19:40:33
【问题描述】：

我有一个奇怪的问题，与通过 cron（通过 crontab -e 调用）运行 BASH 脚本有关。

这是脚本：

#!/bin/bash

SIG1="$(iwconfig wlan0 | awk '/Quality=/ { print $2} ' | cut -c 9-10)"
SIG2="$(iwconfig wlan0 | awk '/Quality=/ { print $2} ' | cut -c 12-13)"

echo "$SIG1:$SIG2" >> test.txt
exit

从命令行运行时，45:70 的预期输出回显到文本文件的末尾。但是，当我通过 cron（使用 crontab -e）和以下条目运行脚本时：

* * * * * bash /home/rupert/test.sh

我只是将冒号 (:) 回显到文本文件中，没有创建值 SIG1 和 SIG2，我不知道为什么。为什么通过 cron 运行会弄乱脚本？

FWIW，这里是 iwconfig wlan0 的输出，没有额外的处理：

wlan0     IEEE 802.11abgn  ESSID:"plumternet"
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:18:84:2A:68:AD
          Bit Rate=54 Mb/s   Tx-Power=15 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=46/70  Signal level=-64 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

我这样做是因为我想在 LCD 屏幕上显示 WiFi 链接质量值“46/70”，而我使用的程序通过读取文本文件来执行此操作。但是，当通过 cron 运行时，值会丢失...???

我正在使用 cut -c 9-10 和 cut -c 12-13 因为我认为“/”可能会导致脚本出现问题，我很乐意使用 cut -c 9-13 ，但我认为它可能会解决问题，但它没有。

救命！！

酷，感谢你们，我意识到这是一个 PATH 问题，只需提供 iwconfig (/sbin/iwconfig) 的完整路径即可修复它。这是现在显示所有正确信息的 LCD 屏幕图片：

http://img835.imageshack.us/img835/4175/20100825122413.jpg

【问题讨论】：

使用-e 开关启动一个bash 脚本是一个好习惯，或者把它放在shebang 行。这样，它会在第一个失败的命令上中止脚本，为您提供失败的命令行编号，并可能有助于避免由于先前失败的命令而导致的数据损坏。

标签： bash cron crontab

【解决方案1】：

您需要提供通过 cron 执行的任何命令的完整路径。 cron 运行与任何终端分离的命令，这意味着您需要正确设置环境。 cut 可能可用，但给出 iwconfig 和 awk 的绝对路径

【讨论】：

你是对的，它需要 iwconfig 的完整路径，我从来不知道！干杯
很高兴有帮助，是的，您提供了通过 cron 执行的所有命令的绝对路径（或者就像任何 shell 脚本中的最佳实践）

【解决方案2】：

将此文件的权限改为777

chmod 777 /home/rupert/test.sh

也许这会有所帮助。

【讨论】：

在我看来，测试的权限不正确（它正在运行...），但权限问题出在 iwconfig。
是的，我认为 .sh 文件的权限还可以，因为它确实可以运行（使用 chmod a+x），但正如 Jasper 所说，这可能是 iwconfig 的问题..
您几乎不应该将 any 文件的权限更改为 777。

【解决方案3】：

我不知道防止这种情况（以干净的方式）发生的确切步骤（我不是 linux 专家），但是，这对我来说似乎是一个权限问题。不允许运行 cron 作业的用户执行您要执行的命令之一。

如果你修复了权限，我认为它可能运行得很好！

【讨论】：

不是权限问题，原来是路径问题；）
这是 cron vs CLI 中可能存在的另一个问题（免责声明：我知道），我只是不认为这是一个问题。