Che tipo di terminale supportare se si implementa un emulatore di terminale??

Chiuso . Questa domanda è basata sull'opinione. Attualmente non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo da poterla rispondere con fatti e citazioni modificando questo post.

Chiuso 4 anni fa.

Migliora questa domanda

Ho sentito che VT100 è lo standard de facto. Significa che se posso semplicemente supportare VT100 e quindi il mio terminale può funzionare per le applicazioni a riga di comando esistenti senza grossi problemi? In caso negativo, come assicurarsi che il terminale sia pratico? C'è qualche riferimento che può aiutare a raggiungere questo obiettivo?

Risposta accettata:

Stai per surriscaldare Thomas Dickey.

Ignora il samizdat che circola da anni sui terminali VT10x. Molto è sbagliato. I DEC VT100, VT101 e VT102 hanno implementato un insieme di funzioni molto specifico, che si può imparare leggendo la loro documentazione.

Questo è non ciò che le persone che girano erroneamente intorno ai termini vt100 e vt102 in realtà significa, tuttavia. Spesso si parla di un'emulazione di terminale che fa molto di di più di quello che ha fatto un vero VT10x, oltre a molto meno . Un vero DEC VT102 aveva una stampante seriale collegata e controllava le sequenze per accedervi, ad esempio. Inoltre non hanno molte delle sequenze di controllo da emulatori di terminale successivi e terminali reali che le persone erroneamente attribuiscono a "vt102". Non aveva il concetto di cambio colore SGR, per esempio.

Hai due scelte di base:

• Implementare qualcosa che sia compatibile con un tipo di terminale esistente definito nei database termcap/terminfo. Se lo fai, devi farlo correttamente, copiando esattamente tutto il comportamento descritto del tipo di terminale esistente. (L'emulatore di terminale del set di strumenti nosh lo fa, emulando su Linux il linux tipo di terminale. Deve copiare linux le codifiche dei tasti estesi e dei tasti funzione stravaganti e limitate del tipo di terminale.)
• Implementa il tuo tipo di terminale, il cui comportamento è progettato da te, che poi devi includere nel database termcap/terminfo. L'emulatore di terminale PuTTY, in senso stretto, fa questo. La descrizione terminfo corretta per esso è putty , putty-256color o putty-sco .

Per il primo, ciò che è standard è irrilevante, poiché devi copiare il comportamento descritto, non importa quanto possa essere non standard. Per quest'ultimo, non cercare standard de facto. Guarda il effettivo standard, alcuni dei quali esistono dal 1976.

• ECMA-48 (pubblicato per la prima volta nel 1976 e successivamente adottato come standard ISO/IEC, ISO/IEC 6429) descrive:
  • Codici di controllo C0,
  • Codici di controllo C1 (che sono poco conosciuti ma si occupano di diverse cose utili come l'impostazione/cancellazione delle tabulazioni e l'indice avanti/indietro)
  • Alias ​​a 7 bit per tutti i codici di controllo C1 (ad esempio, ESC [ è un alias a 7 bit per effettivo carattere di controllo a 8 bit U+009B),
  • Sequenze di controllo introdotte da CSI (per le quali esiste una sintassi generale nello standard per cui molti parser di sequenze di controllo scritti da samizdat sbagliano),
  • e un sacco di altre cose.
• ISO/IEC 2022 descrive il passaggio tra set di caratteri a 7 bit. Se hai intenzione di implementare la funzionalità UTF-8 dall'inizio, è meglio ignorare completamente ISO/IEC 2022, come Markus Kuhn e gli inventori di mosh te lo dirà.
• ISO/IEC 8613-6 (pubblicato nel 1989 e rivisto nel 1994) descrive le estensioni a ECMA-48 per le sequenze di controllo SGR del colore, sia la selezione del "colore indicizzato" da una tavolozza che il "colore diretto" RGB. (Entrambi colore diretto e colore indicizzato sono definiti nella norma ISO/IEC 8613-2. Probabilmente conoscerai quest'ultimo con il nome samizdat di "256 colori".)

  Nota importante: Quasi tutte le implementazioni implementano questo standard in modo errato, perché funzionavano da samizdat (o semplicemente si copiavano l'un l'altro) piuttosto che dallo standard effettivo. Lo standard dice in §13.1.8 di usare i due punti (: , “3/10”) come separatore di sottoparametri; quasi tutte le implementazioni usano erroneamente punto e virgola (; ), introducendo un'ambiguità nell'analisi. Molti software hanno risolto questo errore.

Correlati:cosa indica questo processo STAT?

Ulteriori letture

• Funzioni di controllo per set di caratteri codificati . ECMA-48. 5a edizione. 1991. ECMA Internazionale.
• Tecnologia dell'informazione — Open Document Architecture (ODA) e formato di interscambio:strutture dei documenti . T.412. Unione Internazionale delle Telecomunicazioni.
• Tecnologia dell'informazione — Open Document Architecture (ODA) e formato di interscambio:architetture di contenuto dei caratteri . T.416. Unione Internazionale delle Telecomunicazioni.
• Tecnologia dell'informazione:Open Document Architecture (ODA) e Interchange Format:architetture dei contenuti dei caratteri . ISO/IEC 8613-6:1994. Organizzazione internazionale per la standardizzazione.
• Markus Kuhn (2009). "Quali sono i problemi relativi agli emulatori di terminale UTF-8?". Domande frequenti su UTF-8 e Unicode per Unix/Linux .
• Keith Winstein, Anders Kaseorg, et al. (2012). "Fughe di blocco ISO 2022". informazioni tecniche mosh .
• Manuale di riferimento del programmatore VT420 . EK-VT420-RM-002. Febbraio 1992. Digitale.
• Informazioni sul programmatore di terminali video VT520/VT525 . EK-VT520-RM. Luglio 1994. Digitale.
• Thomas E. Dickey (1997). "Cos'è un VT220?". Domande frequenti su xterm . isola-invisibile.