この問題の回避策や解決策を探していません。。 なぜ機能しないのか理解できません。
次のスクリプトが機能しない理由の詳細な回答を探しています。 unix.stackexchange.comからの投稿を含む、以前のすべてのインターネット検索結果では、これを完全にクリアすることはできませんでした。これは、read
が stdin
はcat
フィードbash
パイプ経由ですか?
bashスクリプトの例test.sh
:
echo "Please say name:" read NAME echo "Hello $NAME"
方法1 bash test.sh
を使用してスクリプトを呼び出す:
$ bash test.sh Please say name: XYZ Hello XYZ $
方法2 bash
:
$ cat test.sh | bash Please say name: $
したがって、スクリプトは入力を待たずに、または2番目の文字を出力することなく、すぐにプロンプトに戻ります。行。
コメント
回答
あなた はread
を使用してstdinから読み取りましたが、読み取ったのは標準入力の次の行、つまり。その行を読んだ後、入力がなくなったため、実行するコマンドもなくなり、スクリプトは終了しました。
標準入力ストリームは 1つだけあり、あなたはコードとデータの両方に使用しようとしています。これは、インタラクティブなbash
セッションが入力からコマンドを読み取る方法やread
応答、および実行する他のコマンドで標準入力を使用する場合。
スクリプトの最後に行を追加すると、これが発生することがわかります。
echo "Please say name:" read NAME echo "Hello $NAME" printf "name=%s\n" "$NAME"
これは、スクリプトが実行を継続することを確認するための追加のコマンドを提供し、NAME
に読み込まれたものを示します:
Please say name: name=echo "Hello $NAME"
変数は、スクリプトファイルに書き込まれたものを逐語的に保持していることがわかります。変数の補間、実行、拡張は行われていません。
端末からread
を実行する場合は、可能です。動作する可能性が最も高い最も簡単な方法は、おそらくTTYに接続されている標準入力(!)ではなく標準出力から読み取ることです。
read NAME <&1
これ私が何かを入力するのを待ってから、プログラムの残りの部分に進みます。 /dev/tty
または$(tty)
を使用することもできます。
コメント
- おそらく
read var </dev/tty
は、stdoutが魅力的なttyに接続されていると想定するよりも優れています。
echo "Hello $NAME"
を待機して受信し、終了しました。