この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
事象
シェルスクリプトにて、JP1の統合トレース(HNTRLib2)を終了するコマンド(/opt/hitachi/HNTRLib2/bin/hntr2kill)の出力結果をif文で判定していたところ、判定結果が正しく表示されなかった為原因を調査しました。
output=$(/opt/hitachi/HNTRLib2/bin/hntr2kill)
if echo "$output" | grep -Eq "hntr2kill: Process \[[0-9]+\] killed"; then
echo "hntr2kill process has been killed successfully"
else
echo "hntr2kill process is not stopped"
exit 100
fi
解決方法
結果、変数output
に格納する際、2>&1
を付け加えることで解決しました。
output=$(/opt/hitachi/HNTRLib2/bin/hntr2kill 2>&1)
if echo "$output" | grep -Eq "hntr2kill: Process \[[0-9]+\] killed"; then
echo "hntr2kill process has been killed successfully"
else
echo "hntr2kill process is not stopped"
exit 100
fi
原因は(/opt/hitachi/HNTRLib2/bin/hntr2kill)
のコマンド出力結果が標準エラー出力(stderr)であり、変数に格納するためには2>&1
が必要だったというわけです。
原因特定までの調査方法
今後の為にも試してみたことを記載しておきます。
スペースの確認
初歩的なコマンドミスはスペースかと思い、スペースが適切な位置に存在しているかを確認。
→問題なし
正規表現
[]内の数字がランダムに変わる為、\[[0-9]+\]
の正規表現に間違いがないかを確認。
→問題なし
grepを文字列のみにしてみる
\[[0-9]+\]
の部分で引っかかっているかと思い、hntr2kill
のみをgrep。
→やはりgrepに引っかからない
コマンドを一つずつ実行(成功への近道)
コマンドを一つずつ実行し、出力結果を確認。
→ここで変数に出力結果が格納されないことが判明。問題が解決へと向かいました。
まとめ
今回学んだことは、コマンドによって動きが違うものがあるということです。
「他のコマンドは同じやり方で動いているから、このコマンドも同じやり方で動くはず」という思い込みが解決を遠ざけていました。
人間も100人いたら100通りの性格があるように、コマンドもそれぞれ性格が違うかもしれないので、そのコマンドの個性を調査した上で早期解決に繋げていこうと思います。