正確には、スクロールバックとスクロールバックバッファーとは何ですか？
bashやscreenなどのプログラムの「スクロールバック」および「スクロールバックバッファー」とは何ですか。また、それらはtty、実行中のプログラム、およびstdin/stdout/stderrとどのように関連していますか？
これが私がこれまでに見つけた "スクロールバック"の唯一の定義です（ archlinux wiki で）：
Scrollbackは、テキストコンソールに実装されている機能であり、ユーザーが画面にスクロールして戻ってきたテキスト行に戻ることができます。これは、ビデオアダプターとディスプレイデバイスの間でこの目的のためにのみ作成されたバッファーによって可能になります。スクロールバックバッファ。
しかし、これは私にとってより多くの質問を引き起こします：
- 「サブルーチン」のように「機能」を意味するのでしょうか？
- このスクロールバックバッファ用のUnix標準またはAPIはありますか？
- ターミナルエミュレーターで起動された
vimで起動されたscreenで起動されたbashで起動されたsshなどのプログラムの「スタック」で、これらのプログラムのどれがスクロールバックバッファーを制御していますか？
また、screenを使用して スクロールバックをファイルにダンプ しました。このファイルの上部には多くの空白があり、ターミナルエミュレーターが「ビュー」に表示するのは、バッファーの最後の数行にすぎないようです。
vimのようなプログラムは、親シェルのスクロールバックバッファーに一時的にアクセスできるため、ターミナルウィンドウ全体を「クリア」できるのはなぜですか。- または、
vimは、親のスクロールバックバッファーの上に何らかの形でオーバーレイされる独自のスクロールバックバッファーを使用しますか？
これは少し複雑な質問です。私はあなたの質問に順番に答えようとしますが、最初に一般的な説明：
スクロールバックバッファーは、ターミナルエミュレーター（xterm、Konsole、GNOMEターミナル）によって実装されます。これには、端末で実行するすべてのプログラムからの標準出力と標準エラーの両方を含め、画面に表示されたすべてのテキストが含まれています。これは完全にターミナル機能であり、スクロールして表示された可能性のある過去の出力を確認したり、以前の発言を確認したりできます。
スクロールバックバッファは、ログ出力の長いページと見なすことができ、ターミナルウィンドウは、常にその一部のみを表示するウィンドウと見なすことができます。上にスクロールしていない場合、見ているのはバッファの最後尾です。通常、ターミナルには、忘れる前に追跡する行数の制限が設定されています。
制限が1000行であるとします。セッションの最初の1000行の出力については、バッファーに追加するだけで、セッションの開始まで右にスクロールできます。出力の1001行目を取得するとすぐに、バッファーの最初の行が消去され、スクロールできる最も遠い後ろがセッションの2行目になります。バッファーには常に、画面に表示された最新の1000行の出力が含まれます。いつでもスクロールアップして、以前の出力を確認できます。
「サブルーチン」または「機能」のように「機能」を意味しますか？
これは「機能」と同じ「機能」です。端末エミュレータには、画面の内容を記録し、画面を上下にスクロールできる機能があります。一部のシステムのコンソールでは、限られたスクロールバックもサポートされています。
screenをミックスに投入すると、少し複雑になります。その時点で、screenはスクロールバックバッファー自体をエミュレートしています。そのため、（たとえば）Xを選択するだけではなく、プログラム内からそれをコピーして貼り付けることができます。このスクロールバックバッファ用のUnix標準またはAPIはありますか？
短い答えはノーです、それはあなたの端末によって提供されるだけです。一番下に到達するより長い答え。
ターミナルエミュレーターで起動されたsshで起動されたbashで起動された画面で起動されたvimなどのプログラムの「スタック」で、これらのプログラムのどれがスクロールバックバッファーを制御していますか？
vimとbashの場合、これらはまったく制御していません（警告、以下で再度）。ターミナルは、シェルから始めて、ターミナル内のすべてのプログラムにスクロールバックバッファーを提供します。上記のscreenは、スクロールバック自体をシミュレートしています。screenを使用して、スクロールバックをファイルにダンプしました。このファイルの上部には多くの空白があり、ターミナルエミュレータが表示する「ビュー」は、バッファの最後の数行であるように見えます。
これは
screenの内部バッファです。そのとき画面に表示されているのは、通常、バッファの一番下にあるものです。これが親シェルのスクロールバックバッファーへの一時的なアクセスを取得するため、vimのようなプログラムがターミナルウィンドウ全体を「クリア」できる理由ですか？
これは、はるかに複雑になる部分の一部です。事実上すべてのXベースのターミナルエミュレータはVT100をシミュレートしており、それらが行う1つのことは、 "代替画面バッファ" をサポートすることです。順次出力を伴うほとんどの端末の対話に使用される通常のバッファーとは異なり、代替画面バッファーは、端末の正確なサイズです。表示されているものより大きくないので、上下にスクロールする必要はありません。
そこにあるアイデアは、フルスクリーンアプリケーションが、すでに画面上にあるものに邪魔されることなく、必要なことを実行できるようにし、その後、以前の画面に正確に戻ることができるようにすることです。そのため、
vimと入力すると画面全体に表示されますが、そのままにすると、以前のターミナル出力（過去のすべてのプロンプトとコマンド出力）が再び表示されます。vimは、開始時に代替画面バッファーに切り替え、終了すると通常のバッファーに戻ります。この代替バッファーは、上記の警告の1つです。時々、プログラムは実際にバッファをどうするかを端末に指示する能力を持っています。
screenはこれを実行する別のプログラムです。そのため、画面セッション中は端末のスクロール機能は通常動作しません—screenはスクロールバックバッファー自体をエミュレートするため、その内部機能を使用して、古い出力を取得します。vimは、親のスクロールバックバッファーの上に何らかの形でオーバーレイされた独自のスクロールバックバッファーを使用しますか？
私はほとんど前の質問でこれに答えましたが、この特定の質問への短い答えは、
vimがターミナルからスクロールバックなしで独自の一時バッファーを取得し、それからすべての独自のスクロールを実行することですドキュメントを内部的に。
私が言及したすべての例外：
再び少し複雑になります。アプリケーションはスクロールバックを制御できず、完全にターミナルによって提供されると述べました。端末によっては、やり取りが制限される場合があります。プログラムは特定のエスケープシーケンスを出力します。これまでに端末の色付けを手動で使用したことがある場合は、それらがどのように見えるかを確認できます。端末はそれらを解釈して動作を変更したり、プログラムに情報を送信したりすることもできます。どのエスケープシーケンスを使用できるかは、 termcap（端末機能）データベース で説明されています。
一部の端末は、スクロールバックバッファの限定的なクエリと操作をサポートしています。多くのxterm派生物には、端末にそのビューをスクロールするように指示するエスケープシーケンスがあります。多くの端末は、画面の特定の領域を指定してスクロールすることもできます。残りの部分はそのままです。それはスクロールバックバッファを壊す傾向があります。
ほとんどすべての端末は、画面上でカーソルを移動するシーケンスをサポートしています。これにより、ncursesライブラリは、ディスプレイのすべての異なる部分を更新できます。 xterm でサポートされている/-VT100シーケンスを確認できます。これらがスクロールバックバッファーと相互作用する方法は、特にlessコマンドのように独自のスクロール動作を実装するものの場合は、少し奇妙な場合があります。 lessが端末の予期しない方法で上部にテキストを再描画したため、スクロールバックの行が重複または欠落する可能性があります。他のプログラムでは、ディスプレイ全体の複数のコピーでバッファがいっぱいになることがあります。