2012-02-14 12 views
0

コマンドラインからスクリプトを正常に実行していますが、cronジョブを実行すると失敗します。私はファイルの存在を[-e "name"]でテストすることで、特に問題を絞り込んだ。これはUbuntuの32ビットのデスクトップで実行されていると、私は次のスクリプトを書いて、コマンドラインから呼び出されたときにそれが動作することができ:Ubuntu 10.04:[-e]テストを使用したときにcronjobでbashスクリプトが失敗する

#!/bin/bash 

# define statements 
IMPORT="/home/${USER}/data_imports/fitb" 
ARCHIVE="${IMPORT}/archive" 
declare -a CENTERS 
CENTERS[0]="ct" 
CENTERS[1]="ny" 
len=${#CENTERS[*]} 
RUNDATE=`date --date=yesterday +"%m%d"` 
ARCHIVEDATE=`date --date=yesterday +"%Y_%m_%d"` 

i=0 
while [ $i -lt $len ]; do 
    if [ -e "${ARCHIVE}/fitb_${ARCHIVEDATE}_${CENTERS[i]}.csv" ] 
    then touch ~/data_imports/fitb/shell_${i}.rn 
    fi 
    let i++ 
done 

私は行をコメントアウトした場合の「if」、「その後」、&」 fi "タッチコマンドをそれ自身の行に置いた後、whileループはcronjobで正常に動作します。 ifテストを入れなおすと、何も得られません。それがcronデーモンによって拾われているかどうかをテストするために、私はシバンの後の行にtouchコマンドを移動したので、最初に実行するコマンドです。これは何も生成しません。私は-eでテストされたファイルが、グローバルなrxパーミッションを持つ適切な場所にあることを知っています。テストが成功するためには+ eが必要なのでしょうか?変数はサブシェルではないことが考えられます(私の理解では、tstはソートです)。そのような場合は、CLIの呼び出しも失敗すると思います。

+0

10回中9回、cronjobが動作しない場合(ただしスクリプトは対話型セッションで動作します)、いくつかの環境変数に問題があります。 – asf107

+0

テストしているファイルを/ tmp/blahなどにエコーして、cronからそれを実行して、それがあなたが期待するファイルであるかどうかを確認してください。そうでない場合は、おそらくasf107が示唆しているように環境変数かもしれません – vmpstr

答えて

2

$ {USER}が定義されていると思われるようです。それはcronjobとして実行している場合はそうではありません。

+0

私はbashテストについて少し読んだ後でそれについて考えましたが、$ {IMPORT}/shell _ $ {i} .rnに触れてテストしました。私はそれをテストすることで何がうまくか分からないが、それは問題だったようだ。私は USER = 'whoami' を入力した可能性があります。これは、cronジョブが正常に動作するようになったためです。ありがとうございました。 – Mange

関連する問題