Red Hat Enterprise Linux 6.4 システムで GNU Screen 4.00.03 を使用すると、少し奇妙な動作が見つかりました。
Screenなしで接続してログを見ると、0x0D 0x0A期待どおりに各行がCRLF（）で終わるのがわかります。
Screenを接続して実行すると、2つ以上の文字を含む行が期待どおりにCRLFで終了します。印刷文字のない行（naked実行などecho）はLF（）でのみ終わり0x0A、最も奇妙なことに、単一の印刷文字（例えばecho x）を持つ行はBSLF（）で終わります0x08 0x0A。
PuTTYを使ってこれを見ましたが、上記のログはPuTTYログからのものです。私はPexpectを使った自動化されたPythonフレームワークでもこれを見たことがあるので、PuTTYを責めることはありません。
どうなりますか？どうやって防ぐことができますか？
ベストアンサー1
これは最適化によって行われますscreen。
echo<Cr>を入力すると、screenローカルエコーとウィンドウの擬似端末デバイス設定のおかげで、icrnlシーケンスがマスター（画面）に送信されます。onlcrscreen\r\n
screen\rカーソルを行の先頭に移動し、\nカーソルを下に移動するように設計された端末エミュレータを実装します。これを行うには、カーソルを行の先頭に移動するためにX API呼び出しを実行するxtermなどの端末エミュレータは、接続されているホスト端末にscreenエスケープコードを送信してカーソルを先頭に移動するように指示する必要があります。ラインの。画面ウィンドウの左側です。
ウィンドウを垂直に分割すると、カーソル位置決めエスケープシーケンスが画面ウィンドウの左側の任意の位置に転送されることを意味します。それ以外の場合、またはホスト端末の左側にある場合は、カーソルが行の先頭に移動し、ホスト端末から1行下に移動するように次の文字を渡します（すべての端末がそのような場合screenでも同様です）。同じ）。\r\n\r\n
それでは、文字echoを実行して出力してみてください\n。onlcrこれはscreenttyウィンドウで再び受信されるためですscreen。行の先頭に移動するように指示しますが、カーソルはすでに行の先頭にあるため、何もする必要はありません。これがホスト端末が2番目の文字を受け取らない理由です。その後、ホスト端末に送受信しながらカーソルを下に移動します。\r\n\r\r\nscreen\n
画面で実行して確認できます。
printf '\r\r\r\r'
screenただ送ることがわかります一つ \rホスト端末に文字を送信します。