いくつかの家庭から始める必要があります。特に、プログラムの1つは、ターゲットプログラムが前のコマンドへの応答の送信を完了するまでコマンドを送信しません。そうしないと、同時に録音されたコンテンツが乱雑に見えることがあります。この仮定が成立するには、シンクとソースの間に挿入されたプログラムがバッファリングを使用しないようにする必要があります。

2つの解決策：

1.ハウジングFDを含むデュアルTシート

シェルスクリプトはバッファリングを無効にし（このユースケースでは非常に重要です）、クライアントプログラムのstdoutをファイルにtee -a logfileリダイレクトし、同時にteestdoutを一時FDに接続します。

同様に、シェル構成を使用して、クライアントプログラムの標準入力として機能するファイル記述子と、プログラムの標準出力として機能する別のファイル記述子を生成できますtarget。その後、他のパイプを介して2つの記述子によって形成された「応答」の方向を配管しますtee -a logfile。

最後に、最初のteestdoutストリームを入力として使用しtarget、2番目のteestdinストリームを出力として使用します。

2. プロセスのデバッグ

さまざまな方法を使用して、ターゲットまたはクライアントプロセスが読み書きするものに接続して記録することができます。

適切なLD_PRELOADを使用すると、readプログラムのstdinおよびstdoutと対話するlibcおよび呼び出しを傍受して記録できます。write問題：すべてがlibcを使用しているわけではありません。

または、以下が推奨されます。 bpftools は、基本的なシステムコールをキャプチャするリスニングの例を提供します。これを解決する方法はありません。フィルタに表示される内容を記録してください。