#!/bin/ksh
(some code)
Log=~/my.log
chown USER1 filename
su - USER1 -c "
date | tee -a ${Log} 2>&1;
cd /blah/blah
if [ SOMECONDITION ]
then
sh ./somescript.ksh > logfile
fi
exit" | tee -a ${Log} 2>&1;
スクリプトは、USER1 に切り替えると停止する傾向があり、手動で終了する必要がある場合に再度実行されます。
答え1
パスワードの入力を要求しているのにパスワードを取得できないため、スクリプトは「su」コマンドで停止すると予想されます。
多くの場合、これには複数の解決策があります:)
「su」の代わりに、標準入力からパスワードを受け入れるための -S スイッチを持つ「sudo」を使用します。
echo "password" | sudo -S -u USER1 sh -c "...
あるいは、別のユーザーとして実行する必要があるアプリケーション/スクリプトのセクションをヘルパー アプリケーションに移動します。その後、そのヘルパー アプリケーションで set-uid と set-gid を使用することで、保存されたクリア テキスト パスワード (セキュリティ上の懸念があります) を使用したスクリプトを回避できます。
chown USER1.GRP1 helperapp
chmod 6755 helperapp
これに伴うリスクは、システム上の誰でも helperapp を USER1 として実行できるようになることです。set-uid/gid を使用する代わりに、configure sudo を使用して、特定のユーザーがパスワード プロンプトなしで helperapp を USER1 として実行できるようにすることができます (これには管理者/ルート権限が必要です)。
# /etc/sudoers
# Allow USER2 to run helperapp as USER1 without prompting for a password
USER2 ALL=(USER1) NOPASSWD:/path/to/helperapp
コードは次のようになります。
#!/bin/ksh
(some code)
Log=~/my.log
chown USER1 filename
sudo -u USER1 /path/to/helperapp | tee -a ${Log} 2>&1;
これらはいずれもテストされていないため、自己責任で使用してください...
答え2
を実行しているので、ログイン シェルを実行するようにsu -
指示しています。ログイン シェルは引数を無視し、代わりに対話形式でコマンドを読み取ります。解決策は を渡さないことです。su
-c
-
対象ユーザーのスタートアップ ファイルを読み取る場合は、明示的に実行します。
su - USER1 <<EOF
date
if [ -e ~/.profile ]; then . ~/.profile; fi
…
EOF 2>&1 | tee -a -- "$LOG"