次のスクリプトがあります。
#!/bin/bash
D=~/brew\ update
num=$(ls "$D" | cut -d ' ' -f 2 | sort -nr | head -1)
num=$(( num + 1 ))
script -q "$D/brew_update $num" brew update
このスクリプトは常に機能しますが、cronで始まると0 */5 * * * ~/bin/brewupdate2ファイルに次のように表示されます。/var/mail
^Dscript: brew: No such file or directory
だから使うと思いましたがsh、使ってみるとsh ~/bin/brewupdate2エラーなく実行されました。
ベストアンサー1
D=~/brew\ update
# the above will never work unless you start script as you
# say you are user fred, this full path will always work
D=/home/fred/brew\ update
Cronはユーザーとは異なる権限とパスを使用します。つまり、cronは基本的に独自のユーザー（ルート）であり、独自のPATHなどを持っています。 ~/ を使用しないでください。 cron ジョブの開始時に、ホームディレクトリ以外のホームディレクトリを参照します。 ~/は、ジョブを開始したシステムのユーザーホームディレクトリ（この場合はルート）に相対的です。 「brew update」のフルパスを使用します（可能であれば、ディレクトリ名とディレクトリ名がユーザーの制御下にある場合はスペースを削除します）。パス生成の観点から、cronが〜/で何をしているのかわかりません。期待どおりに動作しないので、そのような点を考慮したことはありません。
cron を使用する場合は、必ずシステムパス全体を使用してください。それ以外の場合、このタイプのエラーが発生します。
~からサーバー障害:
[cron]はどのユーザーとして実行されますか？
それらはすべてrootとして実行されます。他の方法が必要な場合は、スクリプトでsuを使用するか、ユーザーのcrontab（man crontab）またはシステム全体のcrontab（CentOSでは場所が不明）にcrontabエントリを追加してください。
したがって、理論的にはルートのホームディレクトリである/root/に変換される~/を使用することができますが、これは再び読みやすさやテストなどにとって非常に悪い考えです。
[更新]上記のように、ここでの問題は、"brew"がcronの$ PATHにない/usr/local/binにあることです。これにより、「brew」コマンドが失敗し、ファイルが見つかりません。最後の行を逃した。しかし、常にフルパスを使用する理由がさらに増えました。すべてのプログラムとファイルへのフルパスは、これらすべての問題を解決します。