netcat入力を受け取り、それをファイルにリダイレクトするサーバー上のプロセスをリモートで開くスクリプトを作成しています。
ssh $remote_upload_user@remote_upload_address "nc -l -p $remote_port > $remote_dir/$backup.gz&"
スクリプトは引き続きZFSスナップショットを圧縮し、データをpigz入力として次に送信しますnetcat。
netcat $remote_upload_address -u $remote_port < $(zfs send -R $zpool@label | pigz)
最後に追加すると|pv（括弧内に）データが処理されていることを示しますが、データが渡されると、クライアントの標準出力に無限に歪んだデータストリームが表示されます。pigzpigznetcat
サーバーは、作成する必要があるファイルのサイズがゼロ増加したことを示します。なぜこれがうまくいかないのですか？
ベストアンサー1
$(...)コマンドの置換です。の出力が読み取るzfs sendファイル名になることを望まない。の出力をに入力に送信し、その出力をに送信しようncとします。zfs sendpigzpigznetcat
zfs send -R "$zpool@label" | pigz | netcat "$remote_upload_address" "$remote_port"
UDPを使用しないでください。 TCPとは異なり、UDPは転送保証を提供しません。
リダイレクト演算子を使用するには、-styleを<使用できます。kshプロセス交換（zshおよび江戸ありbash）：
netcat "$remote_upload_address" "$remote_port" < <(
zfs send -R "$zpool@label" | pigz)
ただし、これは標準ベースの同等製品に比べて利点はありません|。そこからリダイレクト演算子に渡されるファイル名は、<名前付きパイプまたは/dev/fd/xパイプを指す特別なファイルです（pigzパイプのもう一方の端に書き込まれます）。
これは同じですが、いくつかの追加のシステムコールが必要です。別の違いは、シェルがコマンドを待たないことですzfs send|pigz（待ってもnetcat出力を読み取る前に終了しない可能性があります）。pigz
または、yashプロセスリダイレクト演算子を使用してください。
netcat "$remote_upload_address" "$remote_port" <(
zfs send -R "$zpool@label" | pigz)
ここでも、標準構文に比べて利点はありません。yashプロセスリダイレクトは通常、コマンドの複数のfdを他のコマンドのパイプに接続する場合に使用されます。