/dev/nullEOFをすぐに返すのではなく、永久にブロックを引き起こすバリエーションをread探しています。そのようなデバイスがありますか？
目的の効果を得るために（経由で）名前付きパイプを作成することもできますが、スクリプトの最後mkfifoでFIFOの切断を処理したくありません。
状況に応じてRPCサーバーがシャットダウンするのを待ちたいです。ポーリングを避けるために、netcatを介して接続を開きます。
netcat localhost 12345
サーバーがシャットダウンすると、接続は自動的に終了します。残念ながら、SSHを介してコマンドを実行するとstdinはに設定されるため、/dev/null接続が閉じるのを待たずにEOFを送信した後、netcatはすぐに終了します。netcat -d（stdinを待ってはいけません）バグはありますか？ macOSとhotでは、このソリューションは実際に合理的な間隔でポーリングするよりも悪いことを意味します。
私はこの問題に対する解決策を持っています。標準入力をパイプに接続することです。しかし、私は純粋な好奇心のためにこの問題に特に興味があります。
ベストアンサー1
残念ながら、SSH経由でコマンドを実行すると、接続が閉じるのを待たずに転送後すぐにシャットダウンするように
stdin設定されています/dev/null。netcatEOF
バージョン4では、パイプを介して親プロセスに接続し、常に開いているが空のプロセスからデータを読み取るbash共同プロセスを作成できます。この方法ではクリーンアップは必要ありません。readstdout
例:
coproc read # Never writes anything into its stdout.
netcat localhost 12345 <&${COPROC[0]} # Read from co-process' stdout.
もう一つの方法はlongstdinからstdoutパイプすることですsleep。
sleep 365d | netcat localhost 12345