Je me demandais comment la "GUI" d'une application en ligne de commande est communiquée sur un réseau. La plupart du temps, c'est assez simple (texte brut / saisie) mais parfois c'est plus complexe (aptitude).
Est-il défini par une sorte de standard afin que chacun puisse écrire son propre terminal et que toutes les implémentations de terminaux se comportent de la même manière (couleurs, positionnement, etc.)?
Réponses:
Les programmes de console utilisent généralement des curses ou l'un de ses successeurs¹ pour créer les types d'interfaces utilisateur de texte dont vous parlez.
Ces bibliothèques utilisent l'une des deux bases de données, appelées termcapet terminfo.² Ces bases de données contiennent des cartes qui indiquent à la bibliothèque les codes à envoyer pour obtenir les actions souhaitées avec un grand nombre de types de terminaux différents. La grande majorité des types de terminaux que vous trouverez définis dans ces bases de données n'ont pas survécu à l'époque des vrais terminaux , et ne sont donc plus d'intérêt historique.
Les émulateurs de terminaux Unix modernes³ utilisent le protocole ANSI X3.64 ou l'une de ses variantes ultérieures:
ANSI X3.64 : Un standard pour contrôler les "terminaux en verre" - par opposition aux télétypes - il est basé sur des séquences spéciales de caractères que le terminal distant interprète. Par exemple, si la boîte Unix veut dire à un terminal compatible ANSI X3.64 de déplacer son curseur dans le coin supérieur gauche de l'écran, il envoie les caractèresESC [ 1 ; 1 H. Les deux premiers caractères indiquent au terminal de s'attendre à une séquence de contrôle, les 1 sont la ligne et la colonne, etHc'est la commande qui signifie "déplacer le curseur" .⁴
Anecdote: de nombreux PC BBS utilisent également des codes ANSI. ( Toujours le cas , en fait.)
DEC VT100 : Le premier terminal en verre compatible ANSI vraiment populaire était le VT100 de Digital Equipment Corporation. En prouvant la norme de jure de l'ANSI sur le marché, elle a établi une norme de facto qui est toujours importante aujourd'hui.
Parfois, vous voyez ce que l'on appelle le protocole VT102, qui est une version à coût réduit - et donc plus populaire - du VT100 plus toutes les options d'extension disponibles intégrées.
Les protocoles de terminal DEC sont une série rétrocompatible, s'étendant du premier modèle compatible ANSI introduit en 1978 (le VT100) jusqu'aux modèles de la série VT500 produits par Boundless Technologies après avoir acheté l'entreprise de terminaux à DEC en 1995. (Boundless est maintenant fermé, mais leurs terminaux apparaissent de temps en temps sur le marché utilisé.)
xterm : une sorte d'amalgame d'ANSI et des normes VT, quelles que soient les normes. Chaque fois que vous utilisez un émulateur de terminal GUI commextermou l'un de ses dérivés, vous utilisez généralement également lextermprotocole de terminal, généralement le plus modernexterm-colorou lesxterm-color256variantes.
Linux : La console Linux utilise également une variante étendue du protocole de terminal ANSI, dans le même esprit que lesxtermprotocoles. La plupart de ses extensions ont à voir avec les différences entre un PC et un terminal en verre. Par exemple, le clavier IBM a des touches qui ne se trouvent pas sur un DEC VT, peu importe. (Et vice versa.)
Certains systèmes Unix ont également leur propre protocole de terminal de console. Il y a la scoansivariante ANSI X3.64 pour SCO Unix, par exemple.
Un programme d'émulation de terminal typique est en quelque sorte un bâtard et n'émule aucun modèle de terminal unique exactement. Il peut prendre en charge 96% de toutes les séquences d'échappement DEC VT jusqu'au VT320, mais prend également en charge des extensions telles que la couleur ANSI (une fonctionnalité VT525) et un nombre arbitraire de lignes et de colonnes. Les 4% de codes qu'il ne comprend pas peuvent ne pas être manqués si vos programmes n'ont pas besoin de ces fonctionnalités, même si vous avez dit curses(ou peu importe) que vous souhaitez que les programmes l'utilisant utilisent le protocole VT320. Un tel programme pourrait se présenter comme compatible VT320, alors même si, à proprement parler, il ne l'est pas.⁵
Il existe quelques autres normes notables que vous rencontrez parfois:
Wyse : L'un des premiers producteurs indépendants de terminaux en verre, Wyse a commencé à fabriquer des terminaux au début des années 1980 avant que l' informatique de poste de travail ne commence à déplacer les mini-ordinateurs. Bien que les terminaux Wyse aient pu émuler le VT100 et d'autres protocoles de terminaux populaires, ils avaient également leurs propres codes natifs.
IBM 3270 : Bien qu'il ne s'agisse pas strictement d'un type de terminal "Unix", la nécessité de connecter les systèmes Unix aux ordinateurs centraux IBM a conduit à la création de programmes d'émulation de terminal IBM 3270, que vous pouvez toujours trouver en cours d'utilisation. Les émulateurs pour lesterminaux IBM 5250 ultérieurssont également assez courants, le plus souvent utilisés de nos jours pour se connecter à desmini-ordinateurs AS / 400 et System i .
Tektronix 4014 : Avant que les PC et les postes de travail ne déplacent largement les terminaux en verre et fassent ainsi des graphiques bitmap une fonctionnalité standard, il existait des terminaux graphiques coûteux qui dessinaient des graphiques à l'écran en réponse à des commandes de texte similaires aux séquences d'échappement décrites ci-dessus. La série Tektronix 4010 était probablement la plus populaire.
Ils étaient assez amusants à utiliser. Vous pouvez écrire un programme qui a dessiné un graphique, mais au lieu de simplement l'exécuter pour dessiner sur votre terminal local, vous pouvez rediriger sa sortie vers un fichier:
$ ./my4014program > my-neat-graphic
Vous pourriez ensuite envoyer ce fichier à quelqu'un d'autre, et ils pourraient le catfaire sur leur terminal Tek pour voir le graphique sans avoir votre programme. Une partie du charme était la lenteur de ces terminaux à dessiner, de sorte que vous pouviez voir le graphique s'accumuler pendant plusieurs secondes.
Vous pouvez découvrir la norme de terminal que vous demandez aux bibliothèques cursesd'utiliser en consultant la TERMvariable d'environnement:
$ echo $TERM
xterm-color
Lorsque vous accédez sshà un autre système, la TERMvariable est transportée afin que la boîte Unix distante sache comment communiquer avec votre terminal local.
Parce que beaucoup de ces protocoles sont des variantes ANSI X3.64, et parce que les normes de codage de caractères ASCII et UTF-8 omniprésentes s'occupent de bien d'autres choses, une TERMvariable incorrecte n'est généralement pas catastrophique. Les éléments qui ont tendance à se briser sont les touches étendues comme la page d'accueil et la page précédente, les combinaisons de touches Alt-quelle que soit la forme, et les fonctionnalités d'affichage typographiques comme la couleur, le gras, etc.
Notes de bas de page:
Le plus souvent, ncurses .
Il existe également des concurrents purs et simples de l' cursesAPI, tels que S-Lang .
AT&T a été promulgué terminfoen remplacement de la termcapbase de données de BSD , et il a largement réussi à la remplacer, mais il existe encore des programmes qui utilisent toujours l'ancienne termcapbase de données. C'est l'une des nombreuses différences BSD vs AT&T que vous pouvez encore trouver sur les systèmes modernes.
Ma boîte macOS n'en a pas /etc/termcap, mais c'est le cas /usr/share/terminfo, alors qu'une installation standard de FreeBSD est l'inverse, même si ces deux systèmes d'exploitation sont souvent assez similaires au niveau de la ligne de commande.
minicom, xterm, mintty, Terminal GNOME , Terminal.app , etc.
Les programmes Unix correctement écrits n'émettent pas directement ces séquences d'échappement . Au lieu de cela, ils utilisent l'une des bibliothèques mentionnées ci-dessus, lui indiquant de "déplacer le curseur à la position (1,1)" ou autre, et la bibliothèque émet les codes de contrôle de terminal nécessaires en fonction du TERMparamètre de votre variable d'environnement. Cela permet au programme de fonctionner correctement quel que soit le type de terminal sur lequel vous l'exécutez.
Les anciens terminaux de texte avaient beaucoup de fonctionnalités étranges qui n'étaient pas très utilisées par les programmes, de nombreux programmes d'émulation de terminal populaires n'implémentent tout simplement pas ces fonctionnalités. Les omissions courantes sont la prise en charge des graphiques six pixels et des modes texte double largeur / double hauteur.
Le responsable de a xtermécrit un programme appelé vttestà tester les émulateurs de terminaux VT tels que xterm. Vous pouvez l'exécuter sur d'autres émulateurs de terminal pour savoir quelles fonctionnalités ils ne prennent pas en charge.