bash -n script.sh
シェルスクリプトの構文を検証するために使用できます。ただし、この関数をテストしようとしたときに、このオプションですべての構文エラーを見つけることができないことに気付きました。
例えば:
root@ubuntu:~/testenv# cat test
#!/bin/bash
SEND=1
if [ "$SEND" -eq 0 ]
echo no
fi
それでは、スクリプトをテストしてみましょう。
root@ubuntu:~/testenv# bash -n test
test: line 5: syntax error near unexpected token `fi'
test: line 5: `fi'
それはうまくいきます。ただし、ブラケットの1つを削除するだけの場合:
root@ubuntu:~/testenv# cat test
#!/bin/bash
SEND=1
if [ "$SEND" -eq 0
then
echo no
fi
root@ubuntu:~/testenv# bash -n test
root@ubuntu:~/testenv#
何も起こらなかった!
bashのmanページも確認しましたが、「-n」は次のように記述されています。
-n Read commands but do not execute them. This may be used to check a
shell script for syntax errors. This is ignored by interactive
shells.
これはスクリプトファイルなので、「インタラクティブシェル」ではないでしょうか。では、どうしてこれが起こるのでしょうか?
シェルが単一括弧の条件を実装する方法の非常に奇妙な癖に遭遇したと思います。これ[
はコマンドであり、特殊文字ではありません。システムの実行可能ディレクトリ(おそらく/usr/bin
)を調べると、[
このコマンドを実装する文字通りの名前の実行可能ファイルが見つかります。あなたが次のようなものを書くとき
[ "$SEND" -eq 0 ]
次に、実際には[
4つの引数を使用してコマンドを呼び出しています。
$SEND
-eq
0
]
このコマンド[
は、最後の引数が]
(そうでないと奇妙に見えるため)であることを確認し、残りの引数を組み合わせて条件を形成し、条件のテスト結果を返します。
[
はコマンドであるため、任意の引数のセットを使用してそのコマンドを呼び出すことは構文エラーではありません。確かに、あなたは末尾をオフのままにした場合]
、エラーが発生しますが、エラーがコマンドから来るでしょう[
、ないシェルから。つまり、エラーを取得するには、実際にスクリプトを実行する必要があります。構文チェッカーは、スクリプトに問題があることを認識しません。bashに関する限り、これ[
は単なるコマンド名であり、たとえばmy_custom_conditional_test
、と同じです。
my_custom_conditional_test "$SEND" -eq 0
これで問題ないことは明らかですよね?Bash[
も同じように考えています。
効率を上げるために、bashは実際には実行可能ファイルを使用しないことに注意してください/usr/bin/[
。の独自の組み込み実装があり[
ます。しかし[
、シェルに組み込まれているかどうかに関係なく、人々は同じように動作することを期待しているため、Bash構文チェッカーは独自の[
特別な処理を行うことができません。/usr/bin/[
末尾を付けずに呼び出すのは構文エラー]
ではないため[
、]
。を付けずに組み込みを呼び出すのは構文エラーにはなりません。
これを[[
、多かれ少なかれ同じこと(条件のテスト)を行うが、シェルによって特別な意味が与えられるとは対照的です。[[
コマンドではなく、シェル構文の特別なトークンです。の[[
代わりに記述し[
、対応する末尾を省略した]]
場合、Bashが構文エラーについて文句を言うことになります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加