複数のファイル操作を実行する bash スクリプトがあります。ユーザーがこのスクリプトを実行すると、正常に実行され、数行のテキストが出力されますが、cron で実行しようとすると問題が発生します。実行されているように見えますが (cron ログに開始されたことを示すエントリが表示されます)、何も起こらず、何も出力されず、ファイル操作も行われません。また、実行中のプロセスのどこにも表示されないため、すぐに終了しているように見えます。
いくつかのトラブルシューティングの後、「set -e」を削除すると問題が解決したことがわかりました。現在、システム cron から問題なく実行されています。それでうまくいきますが、エラーが発生した場合にスクリプトが終了するように、 set -e を有効にしたほうがよいでしょう。「set -e」によってスクリプトが終了する理由を知っている人はいますか?
助けてくれてありがとう、
ライアン
2 に答える
を使用set -e
すると、スクリプトはゼロ以外の終了ステータスを与える最初のコマンドで停止します。これは、必ずしもエラーメッセージが表示されることを意味するわけではありません。
false
これは、エラーステータスで終了する以外に何もしないコマンドを使用した例です。
なしset -e
:
$ cat test.sh
#!/bin/sh
false
echo Hello
$ ./test.sh
Hello
$
しかし、set -e
何も出力せずに終了する同じスクリプト:
$ cat test2.sh
#!/bin/sh
set -e
false
echo Hello
$ ./test2.sh
$
あなたの観察に基づくと、スクリプトが出力を生成する前に、何らかの理由で(おそらく、ジム・ルイスが示唆したように、異なる環境に関連して)スクリプトが失敗しているように思われます。
set -x
デバッグするには、スクリプトの先頭(および)に追加して、set -e
実行中のコマンドを表示します。
スクリプトが cron で実行される場合、環境変数とパスは、スクリプトがユーザーによって直接実行される場合とは異なる方法で設定される場合があります。おそらくそれが異なる動作をする理由ですか?
これをテストするには: と のみを実行する新しいスクリプトを作成しprintenv
ますecho $PATH
。このスクリプトを手動で実行して出力を保存してから、cron ジョブとして実行してその出力を保存します。2 つの環境を比較します。違いが見つかると思います...インタラクティブなログインシェルは、「.login」、「.bash_profile」、または同様のスクリプト(ユーザーのシェルによって異なります)をソースすることによって環境が設定されています。通常、これは cron ジョブでは発生しません。これが通常、cron ジョブがログイン シェルで同じスクリプトを実行する場合とは異なる動作をする理由です。
これを修正するには: スクリプトの先頭で、環境変数と PATH を対話型環境に一致するように明示的に設定するか、ユーザーの「.bash_profile」、「.login」、またはその他のセットアップ スクリプト (使用するシェルに応じて) をソースします。再利用。