Questa è una domanda un po 'complicata. Cercherò di rispondere alle tue domande a turno, ma prima una descrizione generale:
Il buffer di scrollback è implementato dal tuo emulatore di terminale ( xterm, Konsole, Terminale GNOME). Contiene tutto il testo che è stato visualizzato sullo schermo, inclusi l'output standard e l'errore standard di ogni programma eseguito nel terminale. È una funzionalità interamente terminale che ti consente di guardare l'output passato che potrebbe esserti passato accanto o di controllare cosa ha detto in precedenza.
Puoi pensare al buffer di scrollback come una lunga pagina di output registrato e la finestra del tuo terminale come una finestra che ne guarda solo una parte in qualsiasi momento. Se non ne hai fatto scorrere uno verso l'alto, quello che stai guardando è la coda del buffer. Di solito ci sarà un limite configurato nel terminale di quante linee tiene traccia prima che inizi a dimenticare.
Supponiamo che il limite sia di 1000 righe. Per le prime mille righe di output nella sessione è sufficiente aggiungere al buffer e scorrere verso l'alto fino all'inizio della sessione. Non appena si ottiene la 1001a riga di output, la prima riga nel buffer viene cancellata e il retro più lontano che è possibile scorrere sarà la seconda riga della sessione. Il buffer conterrà sempre le migliaia di righe di output più recenti visualizzate sullo schermo e sarà possibile scorrere verso l'alto per visualizzare l'output precedente in qualsiasi momento.
Significa "funzione" come in "subroutine" o come in "caratteristica"?
Questa è "funzione" come in "caratteristica". L'emulatore di terminale ha una funzionalità che registra ciò che è sullo schermo e ti consente di scorrere su e giù in esso. Le console su alcuni sistemi supportano anche lo scrollback limitato.
Diventa un po 'più complicato una volta lanciato screennel mix. A quel punto, screensta emulando il buffer di scrollback stesso - ecco perché puoi copiare e incollare da esso all'interno del programma, piuttosto che solo con (diciamo) la selezione X.
Esiste uno standard Unix o API per questo buffer di scrollback?
La risposta breve è no, è solo fornita dal tuo terminale. La risposta più lunga arriveremo in fondo.
In uno "stack" di programmi, come vim lanciato nello schermo lanciato in bash lanciato in ssh lanciato in un emulatore di terminale, quali di questi programmi controllano il buffer di scrollback?
Nel caso di vime bash, non lo controllano affatto (avvertenza, di nuovo, di seguito). Il terminale fornisce il buffer di scorrimento per tutti i programmi al suo interno, a partire dalla shell. screen, come menzionato sopra, sta simulando lo scrollback stesso.
Ho anche usato lo schermo per scaricare lo scrollback su un file. Questo file aveva un sacco di spazio bianco in alto, e sembra che la "vista" che il mio emulatore di terminale mi mostri sia semplicemente le poche righe inferiori del buffer.
Questo è screenil buffer interno. Quello che sarà sullo schermo in quel momento sarà generalmente quello che si trova in fondo al buffer.
È per questo che un programma come VIM può "cancellare" l'intera finestra del mio terminale, perché ottiene un accesso temporaneo al buffer di scrollback della shell genitore?
Ecco una parte di dove diventa molto più complesso. Praticamente tutti gli emulatori di terminali basati su X stanno simulando un VT100 e una cosa che fanno lì è supportare un "Alternate Screen Buffer" . A differenza del normale buffer utilizzato per la maggior parte dell'interazione del terminale con l'output sequenziale, il buffer dello schermo alternativo ha le dimensioni esatte del terminale. Non è possibile scorrere verso l'alto o verso il basso perché non è più grande di ciò che viene visualizzato.
L'idea è quella di consentire a un'applicazione a schermo intero di fare ciò che deve fare senza essere disturbato da tutto ciò che avevi già sullo schermo e quindi di farti tornare esattamente al display che avevi prima. Ecco perché quando entri vimriempie l'intero schermo, ma quando lo lasci, l'output del terminale che avevi in precedenza - tutti i tuoi precedenti prompt e output dei comandi - ritorna di nuovo. vimpassa al buffer dello schermo alternativo quando si avvia e torna al buffer normale quando esce.
Questo buffer alternativo è una delle avvertenze che ho menzionato sopra. A volte, il programma ha davvero la capacità di dire al terminale cosa fare con il buffer.
screenè un altro programma che fa questo, motivo per cui la funzionalità di scorrimento del tuo terminale generalmente non funziona mentre sei in una sessione di schermo: screenemula il buffer di scorrimento stesso, quindi devi usare la sua funzionalità interna per arrivare al vecchio output.
O vim usa il proprio buffer di scrollback che è in qualche modo sovrapposto al buffer di scrollback genitore?
Ho principalmente risposto a questa domanda nella domanda precedente, ma la risposta breve a questa particolare domanda è che vimottiene il suo buffer temporaneo, senza scrollback, dal terminale, e quindi esegue tutto il suo scorrimento interno dei tuoi documenti.
Tutte quelle eccezioni che ho citato:
Diventa di nuovo leggermente più complicato. Ho detto che le applicazioni non hanno alcun controllo sullo scrollback e che sono fornite interamente dal terminale. In alcuni casi, con alcuni terminali, l'interazione è limitata. Il programma stampa determinate sequenze di escape - se in passato hai mai usato la colorazione del terminale manualmente avrai visto come appaiono - e il terminale può interpretarle e modificarne il comportamento, o persino inviare informazioni al programma. Le sequenze di escape disponibili sono descritte nel database termcap (capacità terminale) .
Alcuni terminali supportano query e manipolazione limitate del buffer di scorrimento. Molti xtermderivati hanno sequenze di escape che indirizzano il terminale a scorrere la sua vista. Molti terminali supportano anche la specifica di una particolare area dello schermo da scorrere, lasciando tutto il resto intatto. Ciò tende a rompere il buffer di scorrimento.
Quasi tutti i terminali supportano sequenze per spostare il cursore sullo schermo, il che consente alla ncurseslibreria di aggiornare tutte le diverse parti del display. Puoi guardare le sequenze VT100 supportate daxterm . Il modo in cui questi interagiscono con il buffer di scrollback può essere un po 'strano a volte, in particolare nel caso di qualcosa che implementa il proprio comportamento di scorrimento, come il lesscomando. Puoi finire con le righe duplicate o mancanti nel tuo scrollback perché lessridisegna il testo sopra in un modo che il tuo terminale non si aspettava. Altri programmi a volte finiscono per riempire il buffer con più copie dell'intero display.