Quel type de terminal prendre en charge si vous implémentez un émulateur de terminal ? ?

Fermé . Cette question est basée sur l'opinion. Il n'accepte pas de réponses actuellement.

Vous voulez améliorer cette question ? Mettez à jour la question afin qu'elle puisse être répondue avec des faits et des citations en éditant ce message.

Fermé il y a 4 ans.

Améliorer cette question

J'ai entendu dire que VT100 est la norme de facto. Cela signifie-t-il que si je peux simplement prendre en charge VT100 et que mon terminal peut fonctionner pour les applications de ligne de commande existantes sans gros problèmes ? Si non, comment s'assurer que ce terminal est pratique ? Existe-t-il une référence pouvant aider à atteindre cet objectif ?

Réponse acceptée :

Vous êtes sur le point de faire surchauffer Thomas Dickey.

Ignorez le samizdat qui circule depuis des années sur les terminaux VT10x. Une grande partie est fausse. Les DEC VT100, VT101 et VT102 ont implémenté un ensemble de fonctions très spécifiques, que l'on peut apprendre en lisant leur doco.

Ce n'est pas ce que les gens utilisent à tort autour des termes vt100 et vt102 signifie en fait, cependant. Souvent, ils parlent d'une émulation de terminal qui en fait beaucoup plus que ce qu'un vrai VT10x a fait, ainsi que beaucoup moins . Un vrai DEC VT102 avait une imprimante série attachée et des séquences de contrôle pour y accéder, par exemple. De plus, il n'a pas ont de nombreuses séquences de contrôle provenant d'émulateurs de terminaux ultérieurs et de terminaux réels que les gens attribuent à tort à "vt102". Il n'avait aucun concept de changement de couleur SGR, par exemple.

Vous avez deux choix de base :

• Mettre en œuvre quelque chose qui est compatible avec un type de terminal existant qui est défini dans les bases de données termcap/terminfo. Si vous faites cela, vous devez le faire correctement, en copiant exactement tout le comportement décrit du type de terminal existant. (L'émulateur de terminal de l'ensemble d'outils nosh le fait, en émulant sous Linux le linux type de borne. Il doit copier le linux les encodages excentriques et limités des touches étendues et des touches de fonction du type de terminal.)
• Implémentez votre propre type de terminal, dont le comportement est conçu par vous, que vous devez ensuite inclure dans la base de données termcap/terminfo. L'émulateur de terminal PuTTY, à proprement parler, le fait. La description terminfo correcte est putty , putty-256color , ou putty-sco .

Pour le premier, ce qui est standard n'est pas pertinent, car vous devez copier le comportement décrit, même s'il n'est pas standard. Pour ces derniers, ne cherchez pas les normes de facto. Regardez le réel normes, dont certaines existent depuis 1976.

• ECMA-48 (publié pour la première fois en 1976 et adopté plus tard en tant que norme ISO/IEC, ISO/IEC 6429) décrit :
  • Codes de contrôle C0,
  • Codes de contrôle C1 (qui sont peu connus mais traitent de plusieurs choses utiles comme la définition/effacement des tabulations et l'index avant/arrière)
  • Alias ​​7 bits pour tous les codes de contrôle C1 (par exemple, ESC [ est un alias 7 bits pour le réel caractère de contrôle 8 bits U+009B),
  • séquences de contrôle introduites par CSI (pour lesquelles il existe une syntaxe générale dans la norme que de nombreux analyseurs de séquences de contrôle écrits en samizdat se trompent),
  • et plein d'autres trucs.
• ISO/IEC 2022 décrit la commutation entre les jeux de caractères 7 bits. Si vous allez implémenter la capacité UTF-8 dès le départ, il vaut mieux ignorer complètement ISO/IEC 2022, comme Markus Kuhn et les inventeurs de mosh vous le dira.
• ISO/IEC 8613-6 (publiée en 1989 et révisée en 1994) décrit les extensions de l'ECMA-48 pour les séquences de contrôle SGR couleur, à la fois la sélection de "couleur indexée" à partir d'une palette et la "couleur directe" RVB. (Les deux couleur directe et couleur indexée sont définis dans l'ISO/CEI 8613-2. Vous connaissez probablement ce dernier sous le nom samizdat de "256 couleurs".)

  Remarque importante : Presque toutes les implémentations implémentent cette norme à tort, car elles travaillaient à partir de samizdat (ou se copiaient simplement les unes les autres) plutôt qu'à partir de la norme réelle. La norme indique au §13.1.8 d'utiliser deux-points (: , "3/10") comme séparateur de sous-paramètre ; presque toutes les implémentations utilisent par erreur le point-virgule (; ), introduisant une ambiguïté d'analyse. De nombreux logiciels ont pris en compte cette erreur.

En relation :Qu'est-ce que ce processus STAT indique ?

Autres lectures

• Fonctions de contrôle pour les jeux de caractères codés . ECMA-48. 5e édition. 1991. ECMA International.
• Technologies de l'information – Architecture de document ouverte (ODA) et format d'échange :structures de document . T.412. Union internationale des télécommunications.
• Technologies de l'information – Architecture de document ouverte (ODA) et format d'échange :architectures de contenu en caractères . T.416. Union internationale des télécommunications.
• Technologies de l'information – Architecture de document ouverte (ODA) et format d'échange :architectures de contenu en caractères . ISO/CEI 8613-6:1994. Organisation internationale de normalisation.
• Markus Kuhn (2009). "Quels sont les problèmes liés aux émulateurs de terminaux UTF-8 ?". FAQ UTF-8 et Unicode pour Unix/Linux .
• Keith Winstein, Anders Kaseorg, et al. (2012). "Le verrouillage ISO 2022 s'échappe". infos techniques mosh .
• Manuel de référence du programmeur VT420 . EK-VT420-RM-002. Février 1992. Numérique.
• Informations sur le programmateur de terminal vidéo VT520/VT525 . EK-VT520-RM. Juillet 1994. Numérique.
• Thomas E. Dickey (1997). "Qu'est-ce qu'un VT220 ?". Foire aux questions sur xterm . île-invisible.