Demande information sur getchar

Version imprimable

02/07/2015, 09h01
Christophe

Demande information sur getchar

Bonjour,

Je cherche à lire un caractère sur la console. Je me suis tourné vers getchar(). Mon soucis est que des caractères s’affichent jusqu'à l'appui de la touche entrée. La fonction n'est elle pas censée lire un seul caractère ? Le retour dans l'int correspond au code ASCII de la première touche appuyée, les autres touches n'écrasent donc pas mon int mais les caractères suivant sont "perdus" je pense. Et comment gérer la touche entrée si celle-ci arrête getchar ? Et comment gérer les touches spéciales ? exemple ctrl+a : J'ai trouvé un exemple avec la touche flèche vers le haut. Ceci envoi une séquence de codes ASCII suivants :27,91,65 (test avec petit code c trouvé)

Par ailleurs les caractères s'affichent à l'écran en echo. J'ai vu que pour contourner ceci il fallait appeler "/bin/stty raw" et "/bin/stty cooked" mais ceci sera valable pour tout ce qu'il se passe sur le tty et donc pas forcément que pour mon process je pense.

Dois-je utiliser autre chose que getchar ?

Merci pour votre aide.
02/07/2015, 10h03
Invité
Citation:

Envoyé par chrtophe

Bonjour,

Bien le bonjour.

Citation:

Je cherche à lire un caractère sur la console. Je me suis tourné vers getchar(). Mon soucis est que des caractères s’affichent jusqu'à l'appui de la touche entrée. La fonction n'est elle pas censée lire un seul caractère ?

getchar() va lire le premier élément disponible dans le stdin et le retourner.

Citation:

Le retour dans l'int correspond au code ASCII de la première touche appuyée, les autres touches n'écrasent donc pas mon int mais les caractères suivant sont "perdus" je pense.

Ils ne sont pas perdu, ils sont toujours présent dans le stdin. Une fonction comme scanf() par exemple n'est pour ainsi dire qu'une boucle sur un getchar(), visant a vider le buffer stdin.

Citation:

Et comment gérer la touche entrée si celle-ci arrête getchar ? Et comment gérer les touches spéciales ? exemple ctrl+a : J'ai trouvé un exemple avec la touche flèche vers le haut. Ceci envoi une séquence de codes ASCII suivants :27,91,65 (test avec petit code c trouvé)

getchar() gère de lui-même la touche "enter".
Code:

1 2 3 4 5 6 7 8 9 #include <stdio.h> int main(void) { int ret = getchar(); printf("ret : %d",ret,ret); return 0; }
Avec uniquement "enter" affiche bien 10. Selon la table ascii, 10 représente bien une LN : Line feed -- nouvelle ligne.
Par contre, je ne pourrais te dire pour les caractères spéciaux et pour les combinaisons de touche. Il me semble qu'il faille traiter chaque caractère séparément.

Citation:

Par ailleurs les caractères s'affichent à l'écran en echo. J'ai vu que pour contourner ceci il fallait appeler "/bin/stty raw" et "/bin/stty cooked" mais ceci sera valable pour tout ce qu'il se passe sur le tty et donc pas forcément que pour mon process je pense.

Je ne connais pas cette partie, donc ne pourrai m'étendre dessus.

Citation:

Dois-je utiliser autre chose que getchar ?

Sur windows, il y a la fonction propriétaire getch() qui a le même comportement que le getchar(), excepté que celui-ci sort de la fonction dès réception d'un caractère sur le stdin. Il n'est donc pas dépendant de l'appui sur touche "enter".
De mémoire, il n'y a pas d'équivalent dans le monde Unix, il faut donc le bricoler soi-même (mais je ne saurai dire comment).

Citation:

Merci pour votre aide.

De rien :)
02/07/2015, 10h10
imperio

Citation:

Envoyé par archMqx.

Sur windows, il y a la fonction propriétaire getch() qui a le même comportement que le getchar(), excepté que celui-ci sort de la fonction dès réception d'un caractère sur le stdin. Il n'est donc pas dépendant de l'appui sur touche "enter".
De mémoire, il n'y a pas d'équivalent dans le monde Unix, il faut donc le bricoler soi-même (mais je ne saurai dire comment).

J'aurais pensé à une utilisation de select allié à read. ;)

Citation:

Envoyé par imperio

J'aurais pensé à une utilisation de select allié à read. ;)

Je note et testerai ça dans l'après-midi. Merci à toi !

EDIT :

Alors, après test de ceci (basé sur l'exemple de test dans le man select) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
 
int
main(void)
{
   fd_set rfds;
   struct timeval tv;
   int retval;
   char ret;
 
   /* Surveiller stdin (fd 0) en attente d'entrées */
   FD_ZERO(&rfds);
   FD_SET(0, &rfds);
   /* Pendant 5 secondes maxi */
   tv.tv_sec = 5;
   tv.tv_usec = 0;
 
   retval = select(1, &rfds, NULL, NULL, &tv);
   /* Considerer tv comme indéfini maintenant ! */
 
   if(retval){
 
       printf("Données disponibles maintenant\n");
       fread(&ret, 1, sizeof(char), stdin);
       printf("char dispo : %c -- %d ",ret,ret);
 
   }else{
 
       printf("Pas de données depuis 5 secondes\n");
 
   }
 
   exit(0);
}

Problème, on reste dépendant de ce que le terminal nous envoie. Celui-ci attends enter pour valider la chaine et l'envoyer au programme.
Donc, j'ai été voir du côté des fonctions termios :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
int my_getch()
{
	struct termios info;
	int retval;
	// Récupère les infos sur stdin
	tcgetattr(STDIN_FILENO,&info);
 
	// Rends stdin en mode raw
	info.c_lflag &= ~ICANON;
 
	// On effectue les modif immediatement
	tcsetattr(STDIN_FILENO, TCSANOW, &info);
 
	retval = getchar();
 
	// On repasse en mode normal
	info.c_lflag |= ICANON;
	// On effectue les modif immediatement
	tcsetattr(STDIN_FILENO, TCSANOW, &info);
 
 
	return retval;
}

Le passage du terminal en mode raw permet de recevoir les caractères un à un. Ce qui au final réponds à l'attente.

02/07/2015, 19h15
Obsidian
Bonjour,

Citation:

Envoyé par chrtophe

Je cherche à lire un caractère sur la console. Je me suis tourné vers getchar(). Mon soucis est que des caractères s’affichent jusqu'à l'appui de la touche entrée. La fonction n'est elle pas censée lire un seul caractère ? Le retour dans l'int correspond au code ASCII de la première touche appuyée, les autres touches n'écrasent donc pas mon int mais les caractères suivant sont "perdus" je pense. Et comment gérer la touche entrée si celle-ci arrête getchar ? Et comment gérer les touches spéciales ? exemple ctrl+a : J'ai trouvé un exemple avec la touche flèche vers le haut. Ceci envoi une séquence de codes ASCII suivants :27,91,65 (test avec petit code c trouvé)

C'est un problème classique : ce comportement n'est pas dû à ton programme C, ni à la fonction getchar() en particulier, ni mêmes aux arcanes du système UNIX qui chapeaute tout cela : il est dû au fait que ton entrée standard provient par défaut d'un terminal. Un « terminal » étant par définition l'équipement de transmission qui vient prendre place au bout d'une ligne (de communication). Ça peut être une console de travail (donc un combiné écran + clavier) mais ça peut aussi désigner un téléphone mobile dans le cas du GSM, par exemple.

Ceci veut dire qu'en réalité, l'ordinateur central se trouvait dans une grosse pièce isolée de laquelle partait un grand nombre de lignes séries distinctes (à la manière des RS/232) qui aboutissaient chacune à un poste de travail, lequel était formé d'un terminal « bête ». C'est-à-dire que la plupart du temps, ce terminal se contentait d'envoyer par la ligne le caractère saisi par l'utilisateur et d'afficher à l'écran tout caractère qui lui parvenait par la même ligne. Le Minitel était un exemple-type de terminal et si d'aventure, tu en as encore un qui traîne dans un coin, tu t'apercevras qu'il fonctionne exactement de la même façon.

Un terminal était donc une « console » dans le sens où on s'asseyait devant et où il formait un pupitre de travail. C'est par extension que l'on a utilisé le même terme pour définir le mot « console de jeux », là encore dans le sens où l'on venait se tenir devant l'appareil et que celui-ci était fait pour proposer directement les jeux sans avoir à faire de manipulation particulière ou à donner d'ordre.

C'est aussi pour les mêmes raisons que les 32 premiers « caractères » du code ASCII sont des « codes de contrôle » : comme il n'avait pas d'autre moyen d'intervenir sur le terminal que de lui envoyer des caractères, il fallait dès le départ définir des codes spéciaux qui servaient à le piloter et à le placer dans certains modes. C'est aussi pour cela que l'ASCII propose le fameux code ESC (« Escape », 27 en décimal, 33 en octal, 1B en hexadécimal) pour pouvoir « sortir » du flux normal et envoyer des séquences hors-code, ce qui permettait d'une certaine manière de « l'étendre ».

Tout ceci pour dire, donc, que les « terminaux virtuels » que tu utilises aujourd'hui sous Unix à travers les sessions X-Window, tout comme les consoles virtuelles en mode texte de Linux (Alt-F1, F2, F3…) ne sont pas de simples « boîtes DOS » : il s'agit en réalité d'émulateurs reproduisant fidèlement le comportement des vrais terminaux physiques distants. Ça veut dire aussi que comme ces machines sont censées être complètement détachées de la machine sur laquelle ton logiciel fonctionne, celui-ci ne peut pas connaître directement l'état des touches en question.

Or, à des fins d'efficacité, et pour essayer de « factoriser » les utilisations les plus fréquentes, certains dispositifs ont été mis en place. D'une part sur les terminaux et même et, d'autre part, sur les contrôleurs de ligne ou sur les dispositifs d'entrée, ce qui permettait de définir des « disciplines de ligne ». Côté terminal, il y a l'écho local : comme le terminal envoie par la ligne ce que l'utilisateur tape et n'affiche à l'écran que ce qu'il reçoit, alors l'ordinateur est obligé de répéter ce qu'il reçoit du terminal pour que celui-ci l'affiche. Pour éviter du trafic inutile, il est possible de demander au terminal d'afficher directement ce que l'utilisateur tape. Avantage : plus de temps de latence à l'affichage, un trafic considérablement réduit, et une grande simplicité du côté logiciel car autrement, c'est l'application elle-même qui devrait gérer tout cela à chaque fois qu'elle ferait une saisie utilisateur.

Côté discipline de ligne, il est généralement possible de gérer en amont de l'application, soit directement les champs de saisie, soit au moins des buffers de ligne : il se passe à peu près la même chose qu'avec setbuf() et printf(), à ceci près que ces fonctions travaillent en sortie et sont gérées par l'application, via la bibliothèque standard, qu'elle utilise. Dans le cas des terminaux, ça veut dire que tout ce qui est saisi par l'utilisateur va être mis en attente par le système, jusqu'à ce que l'utilisateur en question valide sa saisie avec Enter ou Return. C'est seulement alors que l'intégralité de la ligne arrivera à stdin. C'est pourquoi tu ne parviens, par défaut, à ne lire aucun caractère avant que l'utilisateur ait validé et c'est également pour cela qu'au moment où les caractères te parviennent, tu reçois d'abord le premier.

Ce comportement a beaucoup d'avantages également : il permet non seulement d'économiser beaucoup de trafic, encore une fois, mais également de minimiser les overheads liés à cet envoi (autrement, si ta liaison transitait par une connexion TCP/IP par exemple, il faudrait envoyer un paquet entier pour chaque caractère saisi) mais cela permet également à l'utilisateur de se corriger : par exemple, sous Shell, on peut taper Ctrl-U pour effacer la ligne entière (plus précisément : tout ce qui se trouve avant le curseur). Ce n'est pas qu'un simple raccourci clavier : c'est un code spécial attribué à certaines fonctions du terminal et qui est perçu comme un ordre lorsqu'il est saisi. Ça te permet par exemple d'effacer tout un mot de passe si tu t'es trompé en le saisissant, et ce même si tu ne le vois pas. Et tout cela à l'insu de l'application, ce qui est une bonne chose car autrement, elle devrait non seulement gérer l'écho local mais aussi, et d'une manière générale, toutes les facilités d'édition permettant à l'utilisateur de corriger sa frappe.

À noter que cela se fait sur tous les terminaux électroniques, mais se faisait également sur les dernières générations de machine à écrire dans les bureaux, avant que tout le monde passe au traitement de texte : ces machines étaient devenues électro-mécaniques, avec des touches qui commandaient le lancement d'un marteau mû électriquement, d'une boule ou d'une marguerite. Elles disposaient d'un petit écran LCD 16 ou 20 caractères qui permettait d'avoir un aperçu de la ligne courante et de la corriger. Le texte était physiquement imprimé qu'au moment du retour à la ligne.

Citation:

Par ailleurs les caractères s'affichent à l'écran en echo. J'ai vu que pour contourner ceci il fallait appeler "/bin/stty raw" et "/bin/stty cooked"

Plus précisément, raw et cooked sont des aliases qui veulent dire « brut » (de décoffrage) ou « cuisiné » (aux petits oignons) et qui servent à positionner plusieurs flags d'un coup.

Ceux qui nous intéressent ici sont :
- stty ±echo
- stty ±icanon
La man page Linux de stty est le premier endroit où chercher mais elle est trop imprécise (et mériterait d'être ré-écrite). Celle d'AIX IBM est meilleure : https://www-01.ibm.com/support/knowl...cmds5/stty.htm

Tu peux utiliser termios pour le faire directement depuis le C, à condition de sauvegarder l'état initial au début de ton programme et de le restaurer en sortant, par exemple avec atexit().

Citation:

mais ceci sera valable pour tout ce qu'il se passe sur le tty et donc pas forcément que pour mon process je pense.

C'est vrai mais ton terminal ne sera exploité que par un seul processus à la fois.
Par contre, il est effectivement important de restaurer l'état initial du terminal en fin de programme.

Citation:

Dois-je utiliser autre chose que getchar ? Merci pour votre aide.

Non. Tu as le droit d'utiliser la fonction qui te plaît mais le problème sera le même puisqu'il se situe en amont.

Citation:

Envoyé par archMqx.

getchar() gère de lui-même la touche "enter".

Avec uniquement "enter" affiche bien 10. Selon la table ascii, 10 représente bien une LN : Line feed -- nouvelle ligne.
Par contre, je ne pourrais te dire pour les caractères spéciaux et pour les combinaisons de touche. Il me semble qu'il faille traiter chaque caractère séparément.

Attention au piège : ce n'est pas getchar() qui traite Enter elle-même, c'est la manière dont les retours à la ligne sont représentés sous Unix. « 10 » uniquement sous Unix, et « 13 10 » dans le monde Microsoft. « 13 » correspond au retour chariot et au code '\r', ce qui ramène le curseur au début de la ligne courante. C'est également le code exact renvoyé par la touche Return et par Ctrl+M, laquelle combinaison peut se substituer à cette touche (si, si, essayez !). « 10 » correspond à Line Feed (LF), destiné initialement aux imprimantes et qui fait avancer le papier de la hauteur d'une ligne exactement (sans déplacer la tête). C'est à mettre en parallèle avec Form Feed (FF) qui fait avancer « au formulaire suivant », ce qui en pratique consiste à éjecter la feuille en cours et à mettre la suivante en position (au début, en haut de la page), ou à faire avancer le papier au début du feuillet prédécoupé suivant dans le cas d'une alimentation en continu.

Sur un écran, un LF se traduit donc par la descente du curseur à la ligne suivante et un FF à l'effacement complet de l'écran avec retour du curseur en haut de l'écran. C'est ce qui se passe avec le Vidéotex entre autres, mais FF correspond au code 12, soit « Ctrl+L ». Ce n'est donc pas un hasard si c'est cette combinaison de touches qui permet d'effacer un terminal depuis un Shell UNIX.

« 13 10 » est donc la combinaison qui décrit le mieux ce qui se passe lorsque l'on tape à la machine et que l'on va à la ligne : on pousse le chariot à la main pour le ramener en début de ligne et là, un petit levier permet de faire défiler la page d'une ligne en continuant sur sa lancée. Seulement, deux caractères, c'est très pénible à gérer, surtout quand on utilise justement getchar() pour détecter le retour à la ligne. Donc, par convention, la « nouvelle ligne » a été confondue avec le saut de ligne vertical seul, car il est très fréquent de revenir au début de la ligne courante sur un terminal (par exemple, pour mettre l'affichage à jour, dans le cas d'un compteur ou d'une barre de progression) alors que sauter une ligne SANS revenir au début est relativement rare.

Il n'empêche que c'est encore une fois les terminaux qui font cette conversion eux-mêmes et qu'il est possible, via les mêmes outils, de leur demander de ne pas le faire : c'est pour cela qu'on voit parfois certains terminaux déréglés (par exemple suite à l'affichage du contenu d'un fichier binaire), se mettre à sauter des lignes sans revenir au début.

Citation:

Sur windows, il y a la fonction propriétaire getch() qui a le même comportement que le getchar(), excepté que celui-ci sort de la fonction dès réception d'un caractère sur le stdin. Il n'est donc pas dépendant de l'appui sur touche "enter".

On est bien d'accord que ce n'est possible qu'à partir du moment où l'on a une vue directe sur le clavier : si l'utilisateur se connecte à travers un ssh, par exemple, le problème sera le même : il faudra demander d'une façon ou d'une autre au client d'envoyer directement les caractères pour que l'on puisse les lire.

Citation:

De mémoire, il n'y a pas d'équivalent dans le monde Unix, il faut donc le bricoler soi-même (mais je ne saurai dire comment).

Soit on paramètre le terminal comme décrit au dessus et on utilise les fonctions standard, soit on considère qu'on travaille en local et il faut alors lire le périphérique clavier en particulier. Le mieux, si on travaille sous X-Window, étant de se baser sur les événements KeyPress plutôt que sur l'entrée standard.

Citation:

Envoyé par imperio

J'aurais pensé à une utilisation de select allié à read. ;)

Ça ne te donnera rien de plus dans ce cas précis, mais ce sera nécessaire si tu veux faire d'autres tâches en l'absence de sollicitations de la part de l'utilisateur.
02/07/2015, 20h34
imperio

@Obsidian: Tout à fait, je ne sais pas pourquoi mais je pensais que le terminal était en mode raw (donc même s'il n'y a rien, il retourne si je ne me trompe pas dans le nom). Si ce n'est pas le cas, on est toujours dépendant de l'appui de la touche entrée par l'utilisateur comme l'a signalé @archMqx. (merci à toi d'ailleurs ;)).
03/07/2015, 08h36
Invité

1 pièce(s) jointe(s)

Citation:

Envoyé par Obsidian

Bonjour,

Bien le bonjour,
Je te remercie énormément pour ce complément d'information, vraiment très instructif !

Citation:

Envoyé par Obsidian

....
Tu peux utiliser termios pour le faire directement depuis le C, à condition de sauvegarder l'état initial au début de ton programme et de le restaurer en sortant, par exemple avec atexit().
...
Soit on paramètre le terminal comme décrit au dessus et on utilise les fonctions standard, soit on considère qu'on travaille en local et il faut alors lire le périphérique clavier en particulier. Le mieux, si on travaille sous X-Window, étant de se baser sur les événements KeyPress plutôt que sur l'entrée standard.
...

J'ai une petite confusion quant au propos tenu ici.
Quel est donc le moyen le plus conseillé/meilleur ?
Si je comprends, on utilise termios.h si notre programme est rattaché à un terminal précis. Sinon, on va utiliser les événements KeyPress. J'ai juste ?

Citation:

Envoyé par imperio

@archMqx. (merci à toi d'ailleurs ;)).

Pièce jointe 182152 Au plaisir !
03/07/2015, 11h02
Christophe

Merci pour vos retours.

Donc qu'est ce qui est mieux utiliser termios ou select - read comme proposé ?

Citation:

on va utiliser les événements KeyPress

Comment cela ?
03/07/2015, 11h48
imperio

select - read ne fonctionne que si le terminal est en mode non bloquant, donc il te faudrait passer par termios.
03/07/2015, 14h02
Christophe

ok merci pour les infos.

Je vais tester et voir les comportements.
03/07/2015, 16h31
Obsidian

Citation:

Envoyé par imperio

@Obsidian: Tout à fait, je ne sais pas pourquoi mais je pensais que le terminal était en mode raw (donc même s'il n'y a rien, il retourne si je ne me trompe pas dans le nom). Si ce n'est pas le cas, on est toujours dépendant de l'appui de la touche entrée par l'utilisateur comme l'a signalé @archMqx. (merci à toi d'ailleurs ;)).

Attention : Le mode raw, c'est une configuration particulière du terminal entier. La man page précise :

Citation:

Envoyé par man stty

raw: Identique à -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -isig -icanon -xcase min 1 time 0
Avec « - » : identique à cooked.

Ce qui nous intéresse ici, c'est le mode canonique : c'est de lui que va dépendre la mise en application des disciplines de ligne et la gestion des codes spéciaux permettant l'édition. C'est donc le flag « ±icanon » qui va, dans les faits, provoquer ou non l'envoi immédiat des caractères, ou plus précisément leur « mise à disposition ».

Voir cette page : http://en.wikipedia.org/wiki/POSIX_terminal_interface

Après, il peut effectivement être intéressant — ou pas — de passer directement en mode raw : le principal avantage à mon avis étant la spécification de « min 1 time 0 », dont on ne saisit pas forcément l'intérêt sur le coup, mais qui devient clair à la lecture de la section « non canonical mode » de la page ci-dessus.

On rappelle enfin que raw n'est pas un flag : c'est un raccourci pour mettre tous les flags concernés à la valeur voulue. C'est pour cela qu'on ne le trouvera pas dans termios. Par contre, les BSD définissent quand même la macro cfmakeraw() pour arriver au même résultat.

Citation:

Envoyé par archMqx.

J'ai une petite confusion quant au propos tenu ici.
Quel est donc le moyen le plus conseillé/meilleur ?
Si je comprends, on utilise termios.h si notre programme est rattaché à un terminal précis. Sinon, on va utiliser les événements KeyPress. J'ai juste ?

Non : termios.h définit les appels système et les structures C qui leur sont associées pour pouvoir paramétrer un terminal depuis un programme C. C'est sur eux que s'appuie la commande stty qui, elle, permet à l'utilisateur de faire cela depuis le shell.

Les événements KeyPress n'ont rien à voir, en revanche : ils font partie de la programmation d'applications graphiques X-Window en particulier (un peu comme le mode console ou graphique des applications Windows) : toutes les interfaces graphiques, pour ainsi dire, fonctionnent à base d'événements, et KeyPress est l'un d'eux, mais cela n'a rien à voir avec le C standard, ni avec la programmation système UNIX, ni avec les terminaux en mode texte. Par contre, à partir du moment où ces événements sont réputés exister et que l'on travaille dans l'environnement concerné, c'est eux qu'il faut exploiter, surtout qu'il ont le bon goût de nous prévenir quand une touche est enfoncée et qu'elle est relâchée, contrairement à la lecture d'un flux de caractère qui nous dit juste que ce caractère a été saisi, peu importe la façon.

Attention au piège, là encore : un x-term est un émulateur de terminal qui fonctionne sous X-Window, mais l'application qui y est reliée (la tienne, et éventuellement via le shell) n'en a aucune conscience.

Citation:

Envoyé par chrtophe

Merci pour vos retours.
Donc qu'est ce qui est mieux utiliser termios ou select - read comme proposé ?

Ce sont deux choses qui n'ont rien à voir : select() est intéressant quand on veut surveiller plusieurs flux à la fois.

Citation:

Envoyé par imperio

select - read ne fonctionne que si le terminal est en mode non bloquant, donc il te faudrait passer par termios.

Pas forcément : à la base, le mode bloquant ou non bloquant d'un flux en lecture n'est absolument pas lié au terminal, mais à la gestion des fichiers POSIX : il est tout-à-fait possible d'ouvrir un fichier en mode non-bloquant ou de positionner ce flag a posteriori s'il est déjà ouvert. Par contre, il est possible d'émuler un comportement similaire grâce aux paramètres TIME et MIN du terminal. Mais cela n'est de toutes façons valable que si on travaille en mode non canonique.

Voici ou j'en suis :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 // test.c #include <termios.h> #include <unistd.h> #include <stdio.h> int main() { struct termios info; tcgetattr(STDIN_FILENO,&info); int svg=info.c_lflag; info.c_lflag &= ~ECHO; tcsetattr(STDIN_FILENO, TCSANOW, &info); int entier=getchar(); printf("\nvaleur entier : %d\n",entier); info.c_lflag = svg; tcsetattr(STDIN_FILENO, TCSANOW, &info); char chaine[250]; printf("lecture reste stdin : "); scanf("%s",chaine); printf("contenu de chaine : %s",chaine); return 0; }
Je neutralise bien l'echo. Et à l'appui de la flèche du haut par exemple, je retrouve dans entier la valeur 27 (séquence d'échappement) et les caractères "[A" récupérés dans le flux stdin par scanf. Je ne sais pas comment ça s'appele mais ça me fait penser aux scancodes/breakcodes du BIOS (je pense que ça te parles Obsidian) Si je n'est pas appuyé sur une touche spéciale, scanf attendra une saisie. (j'ai mis scanf juste pour tester la récupération des caractères spéciaux).

Citation:

à la base, le mode bloquant ou non bloquant d'un flux en lecture n'est absolument pas lié au terminal, mais à la gestion des fichiers POSIX : il est tout-à-fait possible d'ouvrir un fichier en mode non-bloquant ou de positionner ce flag a posteriori s'il est déjà ouvert.

ça, ça m’intéresse et je vais regarder pour neutraliser l'obligation d'appui de la touche entrée à l'appel de getchar. Il me reste aussi à tester avec redirection du flux stdin depuis un fichier. Et à récuperer les codes suivant un échappement.

Je serais alors en mesure de créer ma propre fonction "getch"

J'ai vu aussi que je pouvais utiliser la bibliothèque curse, c'est une approche envisageable également.

Citation:

Les événements KeyPress n'ont rien à voir, en revanche : ils font partie de la programmation d'applications graphiques X-Window en particulier

ça je connais avec X-Window, mais ça ne me parlait pas pour le terminal.

03/07/2015, 21h52
Obsidian
Citation:

Envoyé par chrtophe

Je neutralise bien l'echo. Et à l'appui de la flèche du haut par exemple, je retrouve dans entier la valeur 27 (séquence d'échappement) et les caractères "[A" récupérés dans le flux stdin par scanf. Je ne sais pas comment ça s'appele mais ça me fait penser aux scancodes/breakcodes du BIOS (je pense que ça te parles Obsidian)

En fait, « ESC [ » s'appelle « CSI » pour Control Sequence Introducer. C'est une séquence initialement définie par ECMA-48 que l'on a ensuite appelé les « codes ANSI » dans le langage courant. Les touches du curseur n'ont pas de caractère attitré dans le code ASCII, et le déplacement du curseur en soi non plus. Par contre, le standard ANSI a déterminé tout un tas d'action et de configuration qu'un terminal pouvait gérer. Ce sont les fameux terminaux DEC, VT-52, VT-100 et VT-510 entre autres qui ont été parmi les premiers à l'implémenter et qui sont devenus des références.

Le Vidéotex, par contre, mappait les déplacements ←, →, ↓ et ↑ sur les caractères 8, 9, 10 et 11, soit Backspace, Tab, Line Feed (dont on a parlé) et Vertical Tab, ce qui se tient tout-à-fait. Ça faisait aussi Ctrl-H, Ctrl+I, Ctrl+J, Ctrl+K ce qui ressemblait « un peu » aux commandes VI, mais c'est une coïncidence (les flèches étaient imprimées sur les touches du clavier du concepteur). C'était donc vrai avec Télétexte, les Minitels et la famille des 8 bits Thomson qui avait choisi d'adopter ce standard plutôt que l'ANSI des PC. Il faut dire que le Vidéotex était adapté au format 40 colonnes et était nettement moins gourmand en caractères que son homologue, ce qui permettait même de faire des petites animations. Ceux qui trouvaient le Minitel lent n'ont pas essayé d'exploiter le mode Téléinformatique 80 colonnes (au standard ANSI) à travers la connexion 1200 bauds du modem intégré (ou 9600 au maximum sur Minitel 2 via la prise périphérique).

Voir :
http://www.ecma-international.org/pu...s/Ecma-048.htm
http://en.wikipedia.org/wiki/ANSI_escape_code
https://fr.wikipedia.org/wiki/VT100
http://linux.die.net/man/4/console_codes

Donc, "ESC [" est le début d'une séquence plus ou moins longue qui peut servir à n'importe quoi : soit de la part du terminal pour indiquer qu'il s'est passé quelque chose ou pour répondre à une interrogation, soit de l'initiative du serveur pour modifier le paramétrage du terminal en lui-même, par exemple pour changer la couleur du texte, lorsque c'est possible.

Citation:

ça, ça m’intéresse

Regarde du côté de fcntl().

Citation:

et je vais regarder pour neutraliser l'obligation d'appui de la touche entrée à l'appel de getchar.

Ça n'existe pas. On a déjà dit que c'était la façon dont Unix d'un côté et ses terminaux, de l'autre, géraient la chose. On a expliqué plus haut qu'il fallait valider la ligne pour qu'elle soit émise, et comme le code 13 en lui-même n'apparaissait pas, il a été supposé que c'était la fonction qui se chargeait de l'absorber, mais c'est faux.

Citation:

Il me reste aussi à tester avec redirection du flux stdin depuis un fichier.

Absolument, mais tu vas être confronté à deux problèmes :
- Ton entrée standard ne sera plus reliée à un terminal, donc termios n'aura plus d'objet. Ça ne t'empêchera cependant pas de lire les caractères ;
- Les caractères en lecture provenant d'un fichier, ils seront donc forcément disponibles en permanence (sauf sur des périphériques vraiment… vraiment TRÈS lents) mais il faudra gérer le cas de la fin de fichier EOF).
Citation:

Et à récuperer les codes suivant un échappement. Je serais alors en mesure de créer ma propre fonction "getch"

Ça, c'est un point intéressant. Il faut simplement être sûr de bien voir comment est écrite une séquence CSI de façon générale.

Citation:

J'ai vu aussi que je pouvais utiliser la bibliothèque curse, c'est une approche envisageable également.

C'est ce qu'il y a de plus intelligent, en effet.

Voici ou j'en suis.

J'aqi fait des essais avec ncurses. ncurses comporte une fonction getch. Par contre lors de l'appel de la fonction d’initialisation initscr, l'écran est effacé. Il sera restauré lors de l'appel à la fonction endwin. Il faut utiliser des fonctions spécifiques à ncurses telle que wprintw au lieu de printf. Il faut donc que le code soit modifié en conséquence. Ca ne me plait pas trop. Je suis donc plutôt parti sur l'utilisation de termio qui m'a été proposée.

Voici mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 #include <termios.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int my_getch() { struct termios info; char sequence[10]; int svg,pos,entier; tcgetattr(STDIN_FILENO,&info); svg=info.c_lflag; info.c_lflag &= ~ECHO && ICANON; // ~ECHO=noecho ICANON=mode canonique (pas d'attente de entrée) tcsetattr(STDIN_FILENO, TCSANOW, &info); pos=0; entier=getchar(); if (entier==27) { entier=getchar(); sequence[pos]=(char)entier; ++pos; entier=getchar(); sequence[pos]=(char)entier; ++pos; if (entier>=0x30 && entier<=0x39) { do { entier=getchar(); sequence[pos]=(char)entier; ++pos; } while (entier=='~'); sequence[pos]='~'; ++pos; } sequence[pos]='\0'; if (strcmp(sequence,"[A")==0) entier=0403; // fleche haute=27,[A if (strcmp(sequence,"[21~")==0) entier=0420; // touche F10=27,[21~ } info.c_lflag = svg; tcsetattr(STDIN_FILENO, TCSANOW, &info); return entier; } int main() { printf("Appuyer sur une touche : "); int retour=my_getch(); printf("\nvaleur entier : %d\n",retour); return 0; }
Le fonctionnement :

J'appele une 1ère fois getchar. Si le retour correspond à 27, il s'agit d'un code escape, sinon je retourne la touche "normale".
Je récupère ensuite la séquence "ECMA". Le caractère suivant est toujours "[". Le reste est de longueur non fixe. D'après ce que j'en ai compris, soit il y a un code suivant (exemple pour flèche haute : \0x27[A) soit la suite est finie par "~" (exemple touche F10 : \0x27[21~). Mon tableau de char séquence va donc contenir cette récupération. avec des if je compare ensuite les séquences. Mon code ne traite que la touche flèche haute et F10. En, cas de flèche haute je retourne 259. Pourquoi 259 ? car en regardant ncurses.h je trouve ceci :
Code:

1 2 #define KEY_UP 0403 /* up-arrow key */
0403 est pour moi de l'octal et vaut en décimal 259. Il est à noter qu'un code ASCII est limité à 256 caractères (et à 128 en caractères non étendus), je suis donc au dessus. Je ne sais pas à quelle norme ce code correspond (si c'est toujours de l'ECMA). Je me sers de tcsetattr pour désactiver l'echo et l'obligation d'appui de retour chariot.

Reste à gérer l'appui juste sur echap, ce que mon code ne fait pas. Il semblerait que pour cela, d'après ce que j'ai vu sur le net, on considère qu'une séquence est transmise dans un certain délai, donc si pas de caractère après un certain temps ... J'ai vu aussi que ça pouvait poser problème en cas de transmission lente. Si je veux traiter cela, je pense faire un getchar non bloquant avec getchar_unlocked ne bloquant pas le flux (ce qui pourrait aussi être une autre façon de ne pas attendre le retour chariot je pense) après la détection de l'appui d'echap et d'attendre un certain délai (en millisecondes)

07/07/2015, 10h35
imperio

Oula, tu te compliques la tâche ! Fait tout simplement un read de 5 sur un terminal en mode canonique et affiche ce que tu reçois. De mémoire, le "caractère" ESC vaut : "^[", donc 2 chars. Encore une fois, il te suffit de tester et tu verras bien.
07/07/2015, 14h44
Christophe

Citation:

Oula, tu te compliques la tâche ! Fait tout simplement un read de 5 sur un terminal en mode canonique

Tu veux dire que je lis 5 caractères ? Je ne connais pas le nombre maximal de caractères pour ECMA. Si j'ai 3 ou 1 caractères à lire comment cela comporte t'il ?

Je vais tester.
07/07/2015, 15h48
Obsidian
Ne cherches pas à lire toute la séquence d'un coup : si tu veux vraiment ré-implémenter tout cela toi-même, il faut faire une boucle et mettre en place un algorithme stateful, comme un automate type AFD. Ne serait-ce que parce que tu ne peux pas te fier à ton homologue : si pour une raison ou une autre, il t'envoie une séquence incorrecte, ou que la transmission est perturbée par un parasite, cela suffirait à faire planter ton programme qui se retrouverait dans un cas de figure indéfini.

À la place, fais une boucle qui lit l'entrée standard caractère par caractère (même si tu peux faire en sorte de lire d'un coup un bloc de n caractères dans un buffer pour des raisons d'efficacité et travailler ensuite sur ce buffer). À côté de ça, tu définis une énumération qui contient tous les états possibles de ton automate, c'est-à-dire tous les phases du traitement dans lesquelles tu peux te trouver. Par exemple : { fluxnormal, escape, csi, parametrecsi, … }. Tu déclares ensuite une variable qui va conserver l'état dans lequel tu te trouves à un moment donné.

Ensuite, tu choisis la façon dont tu vas traiter le caractère que tu viens de recevoir en fonction de l'état dans lequel tu te trouves :
- Si tu es à ce moment dans « fluxnormal », alors tu vérifies si ton caractères n'est pas un caractères spécial comme ESC. S'il s'avère que c'est le cas, alors tu l'ignores mais tu le traites en conséquence. Et si c'est ESC en particulier, tu passes en état « escape » (en affectant la bonne valeur à ta variable). Sinon, tu restes dans l'état actuel et tu transmets le caractère tel quel à la suite du programme (par exemple, tu l'écris à l'écran) ;
- Si tu es en mode « escape », alors tu vérifies si le caractère qui suit a un sens lorsqu'il suit un ESC, c'est-à-dire s'il forme une combinaison valide. Si ce n'est pas le cas, tu redescends en mode « fluxnormal » et tu envoie d'abord un code « ESC » puis le caractères que tu viens de recevoir. Si par contre, c'est une combinaison valide, alors tu agis en conséquence. Et si le caractère est un « [ », alors tu passes en « csi » ;
- Si tu es en mode « csi », tu vérifies si le caractère correspond à une séquence CSI valide. Si ce n'est pas le cas, tu as deux choix : soit tu abandonnes la séquence, tu repasses là encore en « fluxnormal » et tu envoies tout ce que tu as reçu, soit tu traites quand même la séquence tant qu'elle reste syntaxiquement correcte et tu l'ignores à la fin. Sinon, tu vérifies si la séquence attend un paramètre éventuel. Le cas échéant, tu passes en « parametrecsi » ;
- Si tu es en mode « parametrecsi », tu vérifies si ce que tu reçois est admissible pour un paramètre, lequel est généralement un nombre entier. Autrement dit, tu vérifies si c'est un chiffre de 0 à 9 et dans ce cas, tu mets à jour la valeur du paramètre en fonction de ce que tu viens de recevoir.
Généralement, une séquence CSI, après ses paramètres, se termine avec « ; ».

C'est à toi de parcourir ECMA-48 pour voir si c'est toujours le cas, s'il y a une définition formelle de ces séquences et si la norme leur prévoit une taille maximum. À défaut, tu peux prévoir un buffer suffisamment large (256 caractères par exemple) et t'en servir comme d'un buffer circulaire : de cette façon, la longueur de la séquence peut être potentiellement infinie. Comme tu traites les informations au fur et à mesure, tu ne conserves dans le buffer que celles dont tu as besoin.
07/07/2015, 16h25
Christophe

Obsidian,

ce que je fais :

recup caractère
si différent de 27 fin avec retour de celui ci
sinon
lecture caractère suivant (qui est censé être "[") et stockage dans tampon
lecture caractère suivant et stockage dans tampon
si le dernier caractère est numérique (0 à 9) lecture caractères avec stockage jusqu'à atteinte "~"
test tampon avec chaine correspondant à flèche haute ou F10
si comparaison retour avec codes

Je sais pas si on peut considérer ça comme une machine à état.

Les améliorations à faire : tester les valeurs comme tu l'as signalé (en cas de prob de transmission). Notamment, dans mon code, je ne teste pas si [ sius escape
Je n'ai pas bien compris la longueur des séquences CSI, avec mes tests j'ai vu que soit c'était une lettre et rien d'autre derrière le [ soit des chiffres avec ~en terminaison. De ce que j'en ai vu c'est soit un ou deux chiffres.J'ai besoin de creuser.
08/07/2015, 00h13
Obsidian
Citation:

Envoyé par chrtophe

Obsidian,

ce que je fais :
recup caractère
si différent de 27 fin avec retour de celui ci
lecture caractère suivant (qui est censé être "[")

Non, c'est une erreur. Tu ne peux malheureusement pas faire cette supposition.

« ESC » est le code d'échappement du flux standard défini par ASCII. Il peut être suivi de n'importe quoi. Par exemple, en Vidéotex (= sur le minitel), ESC était immédiatement suivi d'un code de commande qui, lui, ne prenait que très rarement un paramètre. Du coup, 95% de ces commandes spéciales occupaient deux à trois octets maximum, sachant que les plus concises étaient les plus utilisées. Ça rendait la chose très efficace. Ça paraissait déjà lent à l'utilisateur mais le standard ANSI exploité à travers la même connexion était intolérablement lent, alors même que les terminaux originaux travaillait en deçà de cette vitesse, encore. :-(

Toujours est-il que même en s'en tenant au standard ANSI, il y a beaucoup de commandes « implicites » déclenchées immédiatement après un ESC. Par exemple « ESC c », avec un « c » minuscule, soit 1B 63, est la commande de réinitialisation globale du terminal. Ça provoque également l'effacement de l'écran et le retour du curseur à son point de départ (en haut à gauche), mais il n'est pas « autorisé » d'utiliser cette commande (pourtant bien pratique) à des seules fins d'effacement de l'écran.

C'est d'ailleurs précisément pour cette raison que les séquences CSI ont été définis : on a choisi un caractère comme « introduction de séquence » (Control Sequence Introducer : CSI), servant à faire au niveau du terminal exactement ce que ESC sert à faire en soi au niveau ASCII, et de là, on peut exprimer une séquence selon un format défini et de la longueur nécessaire.

Citation:

et stockage dans tampon

lecture caractère suivant et stockage dans tampon
si le dernier caractère est numérique (0 à 9) lecture caractères avec stockage jusqu'à atteinte "~"
test tampon avec chaine correspondant à flèche haute ou F10
si comparaison retour avec codes

Je sais pas si on peut considérer ça comme une machine à état.

Pas vraiment, puisqu'une machine à états tient trace, par définition, de l'état courant dans lequel on se trouve, ce qui peut amener le programme à prendre une décision différente pour un même caractère au même endroit du programme. D'ailleurs, puisque tu en parles, tu multiplies les :
Code:

1 2 3 entier=getchar(); sequence[pos]=(char)entier; ++pos;
… un peu partout dans ton code. En principe, ce bloc ne devrait apparaître qu'une seule fois, en haut de ta boucle : c'est une fois le caractère lu et mis en sécurité dans ton buffer que tu peux l'examiner, en t'appuyant sur la valeur de « entier », par exemple.

Citation:

Les améliorations à faire : tester les valeurs comme tu l'as signalé (en cas de prob de transmission). Notamment, dans mon code, je ne teste pas si [ sius escape

Dans ton cas de figure, tu entres dans un bloc « if » et tu lis un nouveau caractère pour pouvoir terminer la procédure en une seule fois. Au niveau d'un AFD, ce serait comme tout traiter pendant la transition. Parfois, on ne peut pas faire autrement, mais c'est alors beaucoup plus difficile de revenir en arrière et d'annuler la procédure quand on se rend compte que la séquence devient invalide au milieu de la transmission.

Citation:

Je n'ai pas bien compris la longueur des séquences CSI, avec mes tests j'ai vu que soit c'était une lettre et rien d'autre derrière le [ soit des chiffres avec ~en terminaison. De ce que j'en ai vu c'est soit un ou deux chiffres.J'ai besoin de creuser.

Regarde la norme ECMA-48 à la section 5.4. Tout est écrit dedans.

Une séquence CSI, c'est un motif de la forme « ESC [32;15m », où « ESC [ » est le CSI, 32 et 15 sont les paramètres et « m » le code de clôture qui définit également l'action à entreprendre, ici changer la couleur du texte. Plus précisément, le texte dit :
- Le prologue CSI (1B 5B ou « ESC [ ») ;
- Une suite optionnelle de caractères formant le ou les paramètres, compris entre 30 et 3F ;
- Une suite optionnelle de caractères dits « intermédiaires », compris entre 20 et 2F ;
- Le code de clôture, un caractère compris entre 40 et 7E ;
… sachant que dans la table ASCII : « < = > ? »

— l'intervalle 30-3F correspond à « 0 1 2 3 4 5 6 7 8 9 : ; < = > ? » ;
— l'intervalle 20-2F correspond à « ! " # $ % & ' ( ) * + , - . / » (en commençant par Espace) ;
— l'intervalle 40-7E correspond au reste des caractères affichables, c'est-à-dire les lettres majuscules et minuscules, plus les autres caractères spéciaux (crochets, slashes), qui viennent combler l'espace à la fin des deux colonnes normalement consacrées aux lettres.

Il est également précisé que :
- La suite des paramètres, si elle existe, doit forcément commencer dans l'intervalle 30-3B, soit les chiffres de 0 à 9, le « : » et le « ; ». Si elle commence par un caractère parmi « < = > ? », elle est considérée comme privée ou expérimentale (pratique pour les extensions propriétaires spécifiques à certaines implémentations des terminaux) ;
- Si la séquence est bien au format standard, alors ses paramètres doivent être sous la forme de nombres décimaux entiers, séparés par des « ; » et en utilisant éventuellement « : » comme séparateur de sous-chaîne pour un paramètre donné (voir par exemple ceci à ce sujet).
Donc, pour lire une séquence CSI entière, il suffit de détecter « ESC [ » et de lire tout le reste jusqu'à ce que l'on trouve un caractère qui soit supérieur ou égal à « @ » (40h). Ce caractère fait partie de la séquence et indique l'action à entreprendre. Tout ce qui suit ne fait plus partie de la séquence.

Ton « ~ » est donc en fait l'une des nombreuses actions que la séquence de contrôle peut mener. Elle sert effectivement à représenter les touches « étendues » comme Home, Pg.Up, Pg.Down et autres caractères, qui sont surtout spécifiques au PC, en fait. En revanche, les touches du curseur qui existaient dès l'aube des terminaux font chacune l'objet d'une séquence CSI propre : sans paramètre, et terminées respectivement par « A », « B », « C » ou « D ».

Dernier piège, parce que ce ne serait pas drôle sinon : sur PC, « ESC » est souvent représenté par « ^[ ». Le « ^ » est là pour représenter l'élévation de la touche provoqué par le modificateur (Ctrl) et est suivi de la lettre associée, car en principe, Ctrl ne peut être associé qu'avec une lettre de A à Z. « Ctrl » est la touche qui permet d'envoyer les caractères de contrôle de la table ASCII et c'est pour cela qu'on la trouve sur pratiquement tous les terminaux (Minitel compris, d'ailleurs, à partir du Minitel 1B). Cela permet donc d'envoyer les codes de 1 à 26 et c'est exactement pour cette raison que ESC prend la valeur 27 : pour ne pas être considéré (et émis) comme un code de contrôle ordinaire. Il se trouve que le caractère qui suit exactement la lettre Z dans la table ASCII est « [ », d'où cet affichage, pas du tout officiel.

C'est peut-être une coïncidence, c'est peut-être volontaire, mais le fait est qu'il n'a rien à voir avec le vrai caractère 5B qui suit l'ESC de la séquence CSI : Si bien qu'un séquence CSI affichée sur l'écran d'un PC est souvent écrite « ^[[ ». Le premier crochet est un faux, le second est un vrai. :-)

Citation:

Donc, pour lire une séquence CSI entière, il suffit de détecter « ESC [ » et de lire tout le reste jusqu'à ce que l'on trouve un caractère qui soit supérieur ou égal à « @ » (40h)

Là c'est clair. J'ai modifié mon code en conséquence et il est plus simple.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 #include <termios.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int my_getch() { struct termios info; char sequence[10]; int svg,pos,entier; tcgetattr(STDIN_FILENO,&info); svg=info.c_lflag; info.c_lflag &= ~ECHO && ICANON; // ~ECHO=noecho ICANON=mode canonique (pas d'attente de entrée) tcsetattr(STDIN_FILENO, TCSANOW, &info); pos=0; entier=getchar(); if (entier==27) { entier=getchar(); sequence[pos]=(char)entier; ++pos; if (entier=='[') { do { entier=getchar(); sequence[pos]=(char)entier; ++pos; } while (entier<=0x40); sequence[pos]='\0'; if (strcmp(sequence,"[A")==0) entier=0403; // fleche haute=27,[A else if (strcmp(sequence,"[21~")==0) entier=0420; // touche F10=27,[21~ else entier=0; } else { ungetc(entier,stdin); entier=0; } } info.c_lflag = svg; tcsetattr(STDIN_FILENO, TCSANOW, &info); return entier; } int main() { printf("test - Appuyer sur une touche : "); int retour=my_getch(); printf("\nvaleur entier de retour : %d\n",retour); return 0; }
algorithme :
lecture caractere
si caractère lu n'est pas esc je le retourne
sinon
  lecture caractère suivant et mise dans tampon
  si caractere="["
    lecture caractère et copie dans tampon jusqu'à ce que celui soit supérieur ou égal à 40h
    terminaison tampon par ajout "\0"
    analyse tampon (si égal à [A (flèche haute) retourne 0x259, si égal à [21~ (touche F10) retourne 0x272 sinon retourne 0) 
  fin si
  sinon
    remise caractère dans flux (je considère dans ce cas la lecture invalide)
    retourne 0
  fin sinon
fin sinon
Je n'utilise pas de machine à état,et mon code est à mon niveau opérationnel. Grosso-modo si la séquence est non reconnue (ne commençant pas par [ après esc ou n'étant pas flèche gauche ou F10 - les deux touches spéciales que je gère) j'ai un retour de 0.

Pour info, les erreurs de transmissions sont négligeables car je travaille en terminal virtuel (pas de liaison sérielle ou réseau)
Obsidian, je ne tiens pas compte de ton dernier paragraphe du moins dans mon code (gestion de "^"), mais ça n'en ai pas moins intéressant.

Pour avoir un code fiable, il me faudrait gérer dans le cas d'une chaine CSI erronée sa longueur car le codee que j'ai fait tel que présenté présentera un buffer overflow en cas de non présence de caractère supérieur ou égal à 40h, et d'autre part, je ne gère pas l'appui unique sur la touche echap ce qui se présentera clairement. Mon code fonctionne aussi avec une redirection de stdin.

Pour moi mon prob est résolu, et j'ai appris plein de trucs sur le terminal.
Merci encore Obsidian pour le temps consacré et les explications détaillées. Merci également aux autres contributeurs.

J'ai crée ma fonction getch() mais pour un réel projet , il vaudra mieux utiliser une bibliothèque qui gèrera beaucoup mieux que moi le terminal (cf ncurses ).

Je laisse encore la discussion ouverte si qq1 à qq chose à ajouter.

08/07/2015, 18h00
Obsidian
Citation:

Envoyé par chrtophe

Là c'est clair…

Oui, mais c'est quand même une grosse simplification de quelque chose qui n'était pourtant pas fondamentalement difficile de prime abord.

Ce qu'il aurait fallu, c'est que tu reconnaisses le motif qui s'affiche à l'écran quand tu tapes des touches spéciales, que tu découvres par toi-même que c'est une séquence CSI en faisant par exemple une recherche Google avec les codes que tu as lu (et qui t'auraient renvoyé des milliers de pages parce qu'ils sont extrêmement répandus) et que, de là, tu cherches d'une part la définition d'une séquence CSI et, d'autre part, son format. Il faudra ensuite que tu fasses exactement la même chose avec les autres types de trames que tu pourrais rencontrer.
Citation:
Code:

1 2 info.c_lflag &= ~ECHO && ICANON; // ~ECHO=noecho ICANON=mode canonique (pas d'attente de entrée)
Il y a une énorme erreur sur cette ligne. Peux-tu voir laquelle ?

Citation:

Je n'utilise pas de machine à état,et mon code est à mon niveau opérationnel. Grosso-modo si la séquence est non reconnue (ne commençant pas par [ après esc ou n'étant pas flèche gauche ou F10 - les deux touches spéciales que je gère) j'ai un retour de 0.

L'avantage des automates, c'est qu'il fonctionnent en observateur sans dépendre en soi de la cohérence de ton flux. Et surtout, ça te permet d'en faire fonctionner plusieurs en parallèle, chose impossible avec un algo tel que celui que tu nous présentes.

Citation:

Pour info, les erreurs de transmissions sont négligeables car je travaille en terminal virtuel (pas de liaison sérielle ou réseau)

Ce n'est pas « négligeable » : c'est un point à prendre en compte dès les premières lignes de la conception de ton programme : tu dois absolument considérer les données extérieures à ton système comme non fiables et celui-ci ne doit jamais être mis en défaut en cas d'incohérence. Sinon, c'est une faille de sécurité puisque n'importe qui peut le faire planter, éventuellement à distance, en lui envoyant des données avariées.

Citation:

Obsidian, je ne tiens pas compte de ton dernier paragraphe du moins dans mon code (gestion de "^"), mais ça n'en ai pas moins intéressant.

Tu n'as pas à le gérer puisqu'il n'y a rien de tel dans le flux. C'est un artefact uniquement dû à la façon dont les codes spéciaux sont affichés à l'écran.

Citation:

Pour avoir un code fiable, il me faudrait gérer dans le cas d'une chaine CSI erronée sa longueur car le codee que j'ai fait tel que présenté présentera un buffer overflow en cas de non présence de caractère supérieur ou égal à 40h, et d'autre part, je ne gère pas l'appui unique sur la touche echap ce qui se présentera clairement.

En effet. Sachant que la touche Echap sert justement, en principe, à permettre à l'utilisateur d'envoyer ce code et, donc, vaut exactement 1B. Rien ne la distingue en soi du début d'une séquence émise automatiquement par le terminal.

Autre petit détail : les touches Home et End ne font pas partie de CSI, mais de SS3 :-)

Citation:

Pour moi mon prob est résolu, et j'ai appris plein de trucs sur le terminal.
Merci encore Obsidian pour le temps consacré et les explications détaillées. Merci également aux autres contributeurs.
Je laisse encore la discussion ouverte si qq1 à qq chose à ajouter.

Dans ce cas, je passe ta discussion en « résolu » quand même. Tu pourras la repasser à l'état non résolu en recliquant sur le même bouton.
08/07/2015, 19h42
Christophe

Citation:

Ce qu'il aurait fallu, c'est que tu reconnaisses le motif qui s'affiche à l'écran quand tu tapes des touches spéciales

Je l'avais fait Obsdian. En fait je n'ai besoin de gérer que la flèche du haut comme touche spéciale. Au début, avant que tu me donnes l'info sur CSI. J'ai cherché à comprendre le cheminement en analysant le flux avec scanf. C'est en appuyant sur d'autres touches que celles qui m’intéressait que me suis rendu compte que les codes retournés étaient de longueur variable. De mes tests, en était ressorti que soit je me retrouvait avec une séquence \27[ suivi de A, B, C etc .. selon la touche soit \27[ un ou deux chiffre puis ~. Ça fonctionnait. La doc parlant du symbole @ m"a embrouillé. Tu m'as ensuite donné l'explication et j'ai modifié mon code en conséquence.

Code:

info.c_lflag &= ~ECHO && ICANON;

Citation:

Il y a une énorme erreur sur cette ligne. Peux-tu voir laquelle ?

Ce code m'a été donné par archMqx. Comme ça je dirais que le & est en trop, mais je suis pas sûr. Je viens de tester, ça ne change pas le fonctionnement. Ca marche avec ou sans. C'est la 1ère fois que je voyais &= mais je ne suis pas programmeur et ne connais par exemple pas les nouvelles normes C11 ou 14.

Citation:

Ce n'est pas « négligeable » : c'est un point à prendre en compte dès les premières lignes de la conception de ton programme : tu dois absolument considérer les données extérieures à ton système comme non fiables et celui-ci ne doit jamais être mis en défaut en cas d'incohérence

Je le fais. si ma chaine ne retourne ni \27[A ni \27[21~ je retourne 0. Je considères 0 comme une ereur. Le seul cas que je ne gère pas pour le moment, est l'appui sur la touche echap. Après je dis pas que ce que j'ai fait n'est pas améliorable.

Citation:

Autre petit détail : les touches Home et End ne font pas partie de CSI, mais de SS3 :-)

Tu veux m'achever là ? :)

Citation:

Dans ce cas, je passe ta discussion en « résolu » quand même.

Pas de soucis.

Et dernière petite question : les codes escapes des imprimantes sont aussi de l'ECMA ou c'est autre chose ?
09/07/2015, 18h02
Obsidian
Citation:

Envoyé par chrtophe

Code:

info.c_lflag &= ~ECHO && ICANON;

Ce code m'a été donné par archMqx.

Pas tout-à-fait : archMqx t'a donné un code que tu as adapté ensuite et c'est à ce moment que tu as introduit cette erreur.

Citation:

Comme ça je dirais que le & est en trop, mais je suis pas sûr. Je viens de tester, ça ne change pas le fonctionnement. Ca marche avec ou sans. C'est la 1ère fois que je voyais &= mais je ne suis pas programmeur et ne connais par exemple pas les nouvelles normes C11 ou 14.

En fait, il y a plusieurs erreurs :
- Le mode canonique, mis en place par ICANON, est justement le mode où les lignes sont bufferisées et où les caractères de contrôle jouent leur rôle. Il faut désactiver le mode canonique pour recevoir les caractères directement et pas l'inverse ;
- Le champ c_lflag de ta structure, tout comme les autres champs …flag, est un entier dont on utilise chaque bit indépendamment de ses voisins et comme un flag distinct. Il va donc nous falloir un moyen de les mettre chacun à 1 ou à 0 en fonction de nos besoins ;
- « &= » est une syntaxe tout-à-fait valide depuis les premières versions du C. Elle correspond à une auto-affection : « x &= y » est équivalent à « x = x & y », donc un ET logique entre la valeur originale du registre de destination et celle qu'on souhaite lui appliquer. C'est utilisable avec les autres opérateurs, donc « += », « -= », « *= », « /= », « %= » et « |= ». Le dernier est d'ailleurs un OU logique « | » ;
- « ~ » est un NON logique : cela inverse bit à bit tout le contenu de ton registre ;
- Un OU logique correspond à une union mathématique, et donc à une superposition des bits des deux registres ;
- Un ET logique correspond à une intersection mathématique et l'appliquer entre deux registres conservera uniquement les bits qui sont à 1 des deux côtés. C'est pourquoi il faut préalablement inverser la valeur de ECHO avec ~ : pour mettre à zéro les bits marqués et préserver les autres ;
- La ligne que tu as écrite en ajoutant un « & » est donc incorrecte sur le plan logique ;
- Pire que cela, tu as utilisé « && » et pas « & », soit en réalité un pseudo-ET. Les opérandes sont donc d'abord convertis en booléens, et le résultat l'est aussi : autrement dit, le résultat de ton opération sera forcément 0 ou 1. Transposé au champ de bit, ça veut dire que tous les bits seront à zéro à part éventuellement le premier. Du coup, cela efface bien les deux flags que tu voulais nettoyer, mais ça écrase tout le reste également !
Citation:

Tu veux m'achever là ? :)

Non, je m'en suis rendu compte par hasard. :-)
Le pire, c'est que Home et End émis depuis le pavé numérique renvoient bien des séquences CSI, mais que ces deux touches sur un clavier « étendu » envoient une séquence du jeu SS3. C'est à peine plus compliqué : ESC O à la place de ESC [.

Citation:

Et dernière petite question : les codes escapes des imprimantes sont aussi de l'ECMA ou c'est autre chose ?

Sûrement pas de l'ECMA, à mon avis. Après ça dépend de l'imprimante en question : soit c'est une vieille imprimante et il y a des chances qu'elle ne réagisse qu'à l'ASCII ou à un jeu propre qui ressemble assez au Vidéotex, soit c'est une imprimante récente et dans ce cas, elle répondent au Postscript ou au PCL. Ce sont alors des langages à part entière.
09/07/2015, 20h02
Christophe

Citation:

« &= » est une syntaxe tout-à-fait valide depuis les premières versions du C. Elle correspond à une auto-affection : « x &= y » est équivalent à « x = x & y »,

Ok, je vais avoir du mal à m'en souvenir, je ne fais pas assez de C.

Citation:

archMqx t'a donné un code que tu as adapté

oui le code qu'il m'a donné

Code:

info.c_lflag &= ~ICANON;

mon adaptation (avec l'erreur que tu m'as expliqué) :

Code:

info.c_lflag &= ~ECHO && ICANON;

Par contre, même si le code n'est pas bon, cela fonctionne.

J'ai donc corrigé par :

Code:

info.c_lflag &= ~ECHO & ICANON;

et du coup, il me fallait appuyer sur entrée pour finir ma sélection

J'ai donc modifié par :

Code:

info.c_lflag &= ~ECHO & ~ICANON;

Je pense que le fait de devoir mettre un ~ alors qu'il ne fallait pas avant vient de la différence de priorité de traitement entre & et &&

Citation:

Pire que cela, tu as utilisé « && » et pas « & », soit en réalité un pseudo-ET. Les opérandes sont donc d'abord convertis en booléens, et le résultat l'est aussi : autrement dit, le résultat de ton opération sera forcément 0 ou 1. Transposé au champ de bit, ça veut dire que tous les bits seront à zéro à part éventuellement le premier. Du coup, cela efface bien les deux flags que tu voulais nettoyer, mais ça écrase tout le reste également !

Là je peux avoir un sacré prob. même si dans mon cas je n'ai rien constaté, et que je restaure les flags d'origine après traitement, mais bonjour la recherche en cas d'effet de bord ...

Je connais l'inversion ~ et le et logique avec & et j'avais bien compris qu'il s'agissait d'un champ de bits, mais mauvais réflexe && (je programme en amateur et peu). Par contre le « &= » m'était inconnu. donc désolé pour l'accusation archMqx :)

Pour les anciennes imprimantes, je me rappelle des séquences d'échappement et j'y ai pensé tout de suite. Et un flux PCL commence par \27. A mon avis c'est pas hasard. Maintenant c'est pas sûr que les commandes soit les mêmes, mais cela est un autre sujet ...
09/07/2015, 23h12
Obsidian
Citation:

Envoyé par chrtophe

Je pense que le fait de devoir mettre un ~ alors qu'il ne fallait pas avant vient de la différence de priorité de traitement entre & et &&

Non car dans les deux cas, l'inversion sera prioritaire par rapport aux ET logiques. Ta formule était intrinsèquement incorrecte mais fonctionnait « par accident » à cause de l'utilisation du pseudo-ET « && ».

Citation:

Je connais l'inversion ~ et le et logique avec & et j'avais bien compris qu'il s'agissait d'un champ de bits, mais mauvais réflexe && (je programme en amateur et peu).

Chacune des macros ECHO, ICANON et autres représentent à chaque fois la valeur d'un bit isolé du champ concerné, donc 1, 2, 4, 8, 16, 32… ou autre puissance de 2.
- Pour cumuler les flags en question, il faut donc appliquer un OU logique : « ECHO | ICANON ». Par exemple, si ECHO vaut 16 et ICANON vaut 4, cela donnera respectivement en binaire : 00010000 et 00000100. Cumulés avec un OU, on obtient : 00010100 ;
- Pour forcer d'un coup ces bits à zéro, il faudrait donc cumuler leur valeur, PUIS complémenter le résultat avec « ~ », puis enfin appliquer ce masque au champ de bit à l'aide d'un ET logique. Donc « ~(ECHO | ICANON) » ;
- Il se trouve que les lois de la logique, telles qu'énoncées par de DeMorgan (entre autres) veulent que ¬(A | B) = ¬A & ¬B (en quelque sorte, on applique le négateur aux opérandes ET à l'opérateur). Ce qui fait que tu es retombé sur le bon résultat, mais pas forcément pour les bonnes raisons.
Citation:

Par contre le « &= » m'était inconnu. donc désolé pour l'accusation archMqx :)

C'est pourtant bien pratique, et cela fait partie des éléments syntaxiques introduits par le C et repris dans beaucoup de langages apparus ultérieurement. Ça a aussi beaucoup d'avantage, spécialement quand on travaille en C++, mais pas seulement. À très bas niveau (assembleur et électronique numérique), les « auto-opérations » de ce type sont assez répandues : c'est la base même des accumulateurs, par exemple.

Citation:

Pour les anciennes imprimantes, je me rappelle des séquences d'échappement et j'y ai pensé tout de suite. Et un flux PCL commence par \27. A mon avis c'est pas hasard. Maintenant c'est pas sûr que les commandes soit les mêmes, mais cela est un autre sujet ...

Ce n'est effectivement pas un hasard, mais ce n'est sûrement pas en rapport avec l'ECMA. Ce sont plutôt ces deux langages qui ont un ancêtre commun. Tout-à-fait au départ, les ordinateurs n'avaient même pas d'écrans cathodiques et passés les afficheurs à lampes des premières machines expérimentales, les ordinateurs produisaient leur sortie sur des téléscripteurs, qui étaient des imprimantes ressemblant surtout à des machines à écrire télécommandées électriquement, par exemple les Teletype (abrégés en TTY, avec laquelle on désigne toujours aujourd'hui nos terminaux virtuels). Le code ASCII date de cette époque et on remarque que les codes de contrôle servent surtout à gérer un flux de papier.

Les imprimantes personnelles apparues beaucoup plus tard, du temps de la micro-informatique, celle que l'on branchait sur le port parallèle, fonctionnaient toujours sur le même principe et même aujourd'hui, le principe perdure même sur les modèles récents : en l'absence de mode particulier, tout caractère envoyé tel quel à l'imprimante est immédiatement imprimé sur le papier. Avec les matricielles, il suffit de déplacer le chariot et d'attendre la suite. Avec les imprimantes jet d'encre qui sont uniquement feuille-à-feuille et surtout avec les laser, c'est plus compliqué : il faut bufferiser les caractères reçus le temps d'en avoir suffisamment pour remplir une page entière ou, à défaut, établir arbitrairement un cours délai de grâce avant de décider d'effectuer le rendu de la page si le flot se tarit.

Toujours est-il qu'il faut lancer une séquence Esc pour expliquer à l'imprimante que l'on « sort du flux régulier » pour lui adresser une suite d'instructions, ce qui est la sémantique du code Escape original.
09/07/2015, 23h52
Christophe

Citation:

Il se trouve que les lois de la logique, telles qu'énoncées par de DeMorgan (entre autres) veulent que ¬(A | B) = ¬A & ¬B (en quelque sorte, on applique le négateur aux opérandes ET à l'opérateur). Ce qui fait que tu es retombé sur le bon résultat, mais pas forcément pour les bonnes raisons.

Ah oui, je crois que je l'ai vu en cours C ça. Mais ça fait longtemps.... et pas vraiment pratiqué.
10/07/2015, 14h57
Obsidian
Citation:

Envoyé par chrtophe

Ah oui, je crois que je l'ai vu en cours ça. Mais ça fait longtemps.... et pas vraiment pratiqué.

C'est intéressant parce que cela a été formalisé mathématiquement mais ce n'est pas très difficile en soi. Admettons que tu aies une lampe qui soit commandée par deux interrupteurs en amont :
- Si tu as deux interrupteurs A et B en série : pour allumer la lampe, il faut fermer l'interrupteur A ET l'interrupteur B. Pour éteindre la lampe, il faut ouvrir l'interrupteur A OU l'interrupteur B (ou les deux) ;
- Si tu as deux interrupteurs A et B en parallèle : pour allumer la lampe, il faut fermer l'interrupteur A OU l'interrupteur B (ou les deux). Pour éteindre la lampe, il faut ouvrir l'interrupteur A ET l'interrupteur B ;
10/07/2015, 16h07
Christophe

J'ai fait de l’algèbre de Boole en logique combinatoire. Quand j'ai vu le nom de de Morgan, je m'en suis rappelé (sans me rappeler forcément le théorème, ça fait 20ans...)

Du coup je l'ai recherché pour rappel et pour ceux que ça intéresse :

Théorème 1 :
Le complémentaire du OU des variables est égal au ET des complémentaires de chaque variable.
non (A ou B) = (non A) et (non B).

Théorème 2 :
Le complémentaire du ET des variables est égal au OU des complémentaires de chaque variable.
non (A et B) = (non A) ou (non B).

C'est un peu comme une identité remarquable, quand on n'est plus dans le bain ...

Après c'est sûr que c'est pas évident à y penser pour implémenter avec des flags, à la base j'ai vu ça en électronique numérique.
10/07/2015, 16h56
Obsidian
Citation:

Envoyé par chrtophe

J'ai fait de l’algèbre de Boole en logique combinatoire. Quand j'ai vu le nom de de Morgan, je m'en suis rappelé (sans me rappeler forcément le théorème, ça fait 20ans...)

Du coup je l'ai recherché pour rappel et pour ceux que ça intéresse :

Théorème 1 :
Le complémentaire du OU des variables est égal au ET des complémentaires de chaque variable.
non (A ou B) = (non A) et (non B).

Théorème 2 :
Le complémentaire du ET des variables est égal au OU des complémentaires de chaque variable.
non (A et B) = (non A) ou (non B).

Ce qui est en substance ce que je viens d'écrire au-dessus.

Citation:

C'est un peu comme une identité remarquable, quand on n'est plus dans le bain ...
Après c'est sûr que c'est pas évident à y penser pour implémenter avec des flags, à la base j'ai vu ça en électronique numérique.

C'est bien pour cela que j'ai écrit le commentaire au-dessus : si tu l'apprends uniquement comme une simple formule de maths, voire comme tu l'as dit, d'une « identité remarquable », tu n'auras effectivement jamais l'idée d'aller l'utiliser dans un programme alors que :
- C'est un principe qui vient naturellement à l'esprit dans la vie courante (et qui a été démontré mathématiquement ensuite) ;
- Il est nécessaire de recourir aux opérations logiques bit à bit quand elles sont disponibles et que l'on travaille avec des opérateurs plus larges. C'est le seul moyen de faire des modifications individuelles au niveau du bit et, par conséquent, elles font partie du développement logiciel dès les premiers exercices et quelque soit le langage. Même en BASIC, on les utilisait beaucoup (surtout en BASIC, même, car alors les pseudo-ET et pseudo-OU n'existaient pas et parce qu'on faisait par ailleurs beaucoup d'accès directs à la mémoire avec PEEK et POKE).