Discussion :

[Hibou57]

Kikou touti li mondi,

Je fais des essais de programmation sous Linux (je découvre à peine l'API système). Je voudrais lire au clavier, ou du moins sur le périphérique d'entrées standard.

Je fais un syscall pour la fonction de lecture, en donnant le handle °1 (entrée standard). Le problème est qu'il y avoir quelque chose qui fait parasite entre la console et l'application (edline je crois) qui fait que quand le programme s'execute, je suis en mode édition de ligne (pourtant l'historique du shell par exemple, ne devrait concerner que le shell, ça me semblerait plus logique), et je dois taper sur <entrée> pour que le programme puisse lire le moindre caractère entré au clavier. Après la sortie du programme, les caractères restants non-lus sur la ligne qui étaient en cours d'édition, sont envoyés au shell (ce qui m'ennuie fortement).

J'ai pensé résoudre le problème en ouvrant le console (/dev/console), pour y faire une lecture (plutôt que de lire sur le handle 1).

Mais le problème, et je ne comprends pas pourquoi, c'est que ça me renvoie toujours 0 (la valeur zéro). Il n'y a pourtant aucun renvoie d'erreur à l'ouverture de /dev/console.

En fait, il me faudrait un accès en lecture qui courcircuite les parasites intermédiaires (j'insiste, l'historique du shell n'a rien à faire ailleur que dans le shell lui-même), et qu'il n'y ai pas de bufferisation de l'entrée en mode ligne (le shell n'a pas à recevoir les caractère entrée au clavier lors de l'execution du programme après que celui-ci se termine).

Quelqu'un(e) connais t-il/elle les base de l'accès au clavier (ou stdin) sous linux ? J'ai recherché en vain sur google.. car bien que le problème soit surement traité quelque part, google me renvoie toujours des pages sur tout et n'importe quoi (bench d'installations linux, clavier multimédia sous linux, ewa, ewa, ewa).

NB. Je fais des teste de programmation en assembleur (l'assembleur pour raisons persos), en passant directement par les syscall (parce que je n'ai pas besoin qu'un programme qui dit coucou-tout-le-monde pèse 150 Téra bytes).

Faut-il passer par les IOCTL ? (je ne les connais pas)

P.S. Si la question vous semble peu claire ou mal formulée, n'hésitez pas à m'en faire part

[garga69]

pour recuperer les donnees tapees au claviers il y a 'read'
mais je ne suis pas un specialiste
tu peu aussi l'utiliser en redirigent la sortie des autre affichage ce qui feras que tu va lire dans une variable les chaines de caracteres lignes par lignes ''si je fait pas d'erreur''
exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
cat texte.txt|while read i
do
echo $i
done

ou simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
read i 
echo $i

voila je c pas si cela t'aide mais c tout ce que je peu dire en temps que debutant

[Hibou57]

Merci pour ta contribution Garga69... mais c'est assembleur que je programme cette application de teste... alors je ne pense pas utiliser de fonctions shell hihihi (d'ailleur je n'aime pas les shell linux... il sont trop lourds, et les shell légers sont trop pauvres)

En fait j'ai trouvé une solution avec les IOCTL. Concrêtement, je fais passer le terminal en mode non-canonique.... mais il reste quelque chose de bizzare... des comportement étranges de la part du terminal... et je ne comprend pas d'où cela vient (j'essayerai de décrire le problème ici, si par malheur je ne parvenais pas à le résoudre).

C'est en bonne voie en tout cas.

[Hibou57]

Heeelp!

S'il y a des spécialistes en terminaux ici, c'est le moment de montrer comme vous avez du flaire.

Il y a effectivement quelque chose qui cloche.

La logique de mon programme est de mettre le terminal en mode non-canonique avec désactivation de l'echo. Ceci est fait à l'initilisation du programme, juste après quoi le programme commence à lire au clavier.

Je lance le programme, ok.

Je re-lance le programme ok.

Je re-re-lance le programme... ah ? bizzare : je tappe au clavier, et les caractère s'affiche à l'écran, malgré que l'echo soit désactivé et mon programme ne reçoit pas les données que j'entre au clavier. Je tape un, deux, trois caractères... au quatrième caractère, il n'y a plus d'echo et le programme reçois les caractères suivant.

je re-re-re-lance le programme ok.

je re-re-re-re-lance le programme, ça me re-fait presque le même cafouillage, excepté que cette fois-ci, c'est au deuxième caractère que l'echo disparait et que les caractères sont reçus par l'application.

Quelqu'un(e) a une idée de ce qu'il se passe ?

N.B. J'ai essayé les quatres principales configurations timing/taille-buffer (i.e. VTIME et VMIN), mais rien n'y fait. A noter tout de même qu'avec un timing null et un buffer de 1 caractère (VTIME == 0 et VMIN == 1), c'est systèmatiquement que le premier caractère entré au clavier est affiché par echo, alors que la configuration du terminal est déjà effectuée (et donc que echo devrait être desactivé)

[Hibou57]

J'ai trouvé l'origine du problème : j'ouvrais /dev/console, et je faisait une opération IOCTL sur le handle renvoyé. Mais pendant ce temps, le handle #0 (entrée standard) est toujours actif. Je ne pensais pas que cela poserais un problème, parce que l'alias de la console n'était pas utilisé en même que l'handle #0. Aparement, Linux n'aime pas trop quand même, et dans ce cas là, tantôt il traitait les saisies au clavier comme étant à destination de #0 et tantôt comme étant à destination de son alias... j'ignore selon quel critère, d'autant que cela parraissait plus ou moins aléatoire. Un caractère était reçu par mon application, le suivant pouvait être passer à la moulinette du mode canonique, puis le caractère d'après, etc, etc.

... peut-être que le shell y est pour quelque chose... je l'ignore... mais je pense que c'est plutôt le noyau qui a des difficulté à gérer le partage de deux modes d'accès différent à une même console physique.

D'ailleurs j'ai remarqué qu'un problème sur une console virtuelle, pouvait occasioné également des problème sur les autres consoles virtuelles... c'est normal ou pas ? Est-ce un bug du Kernel 2.0 ?

Ca complique les choses tout ça quand même.... parce qu'en cas de redirection d'entré sortie, si on tient à lire effectivement des entré au clavier et non pas depuis une redirection, il faut bien ouvrire /dev/console ou autre quand même.

à suivre ...