Discussion :

[sben42]

Bonjour à tous.

Je développe actuellement une version simplifié de la GNU Readline (Chet Ramey).
Pour se faire j'utilise la librarie termcap.

Je rencontre plusieurs problèmes:


Le premier est lié au fait que je dois constamment connaître la position de mon curseur de manière à pouvoir naviguer (via tgoto) au sein de ma ligne d’édition (left arrow, right arrow, page up, page down, home, end etc..). Termcap ne met rien à disposition pour ça..

Je souhaiterai donc savoir s'il n'y a vraiment rien de plus propre (sans utilisation d'autres librairie) que de la demander au terminal à l'entrée du programme via la séquence CSI 6n, pour parser sa réponse? Et ensuite la mettre à jour selon mes déplacements et affichage..

EDIT:
Problème (erroné de ma part), résolu par Matt_Houston.

You describe the output buffer by its address, buffer, and its size in bytes, size. If the buffer is not big enough for the data to be stored in it, tparam calls malloc to get a larger buffer. In either case, tparam returns the address of the buffer it ultimately uses. If the value equals buffer, your original buffer was used. Otherwise, a new buffer was allocated, and you must free it after you are done with printing the results.

Le second est lié au fait que les fonctions tgetstr, tgoto, tparm et tputs utilisent des buffers internes qu'il m'est impossible (je pense) de free.. Cela signifie t-il qu'à la longue tout programme utilisant ma Readline aura pour vocation de bouffer toute la mémoire?.. Si oui (toujours sans utilisation d'autres librairie) la seule solution qu'il me reste est-elle de générer moi même toutes les séquences CSI que ces fonctions génèrent? (Si c'est bien ce qu'elle font? ^^).
FIN EDIT.

La dernière est lié à la gestion du redimensionnement en cours d’exécution, par l'utilisateur du terminal. Pour le moment je catch le signal SIGWINCH et j'appelle ioctl avec TIOCGWINSZ pour réinitialiser mes valeurs "nombre de ligne affichable" et "nombre de colonne affichable" ainsi que la réponse de la séquence CSI 6n pour la nouvelle position du curseur.

Seulement ça implique au minimum un iocl(), un write(), et un (voir plus) read() au sein du sighandler... En plus du ré-affichage de la partie visible de ma ligne d'édition, le repositionnement du curseur etc... Et je ne suis vraiment pas sur que se soit une bonne pratique..? (POSIX compliance etc...).


On va en rester là pour le moment ^^.
Merci beaucoup à ceux qui se pencheront sur ces questions.

PS: J'ai cherché durant de longues heures et en vain à comprendre l'implémentation de la GNU Readline Library (via ses sources: GNU Readline Source)...
Si quelqu'un aurait un lien (s'il existe) vers une analyse, une discussion, ou autre relative à cette implémentation, je lui en serait très reconnaissant! J'ai lu et relu la doc mais je n'arrive toujours pas à me faire une idée (même simpliste) sur la manière dont elle est pensée/organisée/implémentée etc...

Encore merci.

[Matt_Houston]

Le second est lié au fait que les fonctions tgetstr, tgoto, tparm et tputs utilisent des buffers internes qu'il m'est impossible (je pense) de free.. Cela signifie t-il qu'à la longue tout programme utilisant ma Readline aura pour vocation de bouffer toute la mémoire?.. Si oui (toujours sans utilisation d'autres librairie) la seule solution qu'il me reste est-elle de générer moi même toutes les séquences CSI que ces fonctions génèrent? (Si c'est bien ce qu'elle font? ^^).

Le manuel te donne une réponse assez claire :

You describe the output buffer by its address, buffer, and its size in bytes, size. If the buffer is not big enough for the data to be stored in it, tparam calls malloc to get a larger buffer. In either case, tparam returns the address of the buffer it ultimately uses. If the value equals buffer, your original buffer was used. Otherwise, a new buffer was allocated, and you must free it after you are done with printing the results.

Je n'ai pas les connaissances pour aborder le reste de ton problème.

[sben42]

Bonjour Matt_Houston, et merci pour la réponse.

J'ai en effet extrapolé le comportement décrit par tgetent aux autres fonctions... Après relecture de leurs man (et en fait surtout de la doc présente sur delorie.com) respectif, il s'avère que seul tgetent pose problème.. Celle ci n'étant appelée qu'un fois, j'edit mon message initial, ce problème là étant résolu! Merci beaucoup!

Pour tgetent: J'ai le choix entre un buffer alloué par moi même (mais dont je n'ai aucun moyen de connaître la taille..) et celui alloué par termcap qui ne sera free que lors d'un nouvel appel à tgetent (donc lors d'un second malloc/ou utilisation d'un buffer potentiellement trop petit) Le man:

With the Unix version of termcap, you must allocate space for the description yourself and pass the address of the space as the argument buffer. There is no way you can tell how much space is needed, so the convention is to allocate a buffer 2048 characters long and assume that is enough. (Formerly the convention was to allocate 1024 characters and assume that was enough. But one day, for one kind of terminal, that was not enough.)

Un peu sale je trouve...

If you are using the GNU version of termcap, you can alternatively ask tgetent to allocate enough space. Pass a null pointer for buffer, and tgetent itself allocates the storage using malloc. There is no way to get the address that was allocated, and you shouldn't try to free the storage.

Bref au pire, normalement la fuite ne devrait pas dépasser les 2Ko..

[Matt_Houston]

Termcap est une antiquité qui a été pratiquement totalement remplacée par terminfo ou autres, je ne me formaliserais pas trop à ta place.

La description d'un terminal est explicitement limitée à 1023 caractères (cf. https://en.wikipedia.org/wiki/Termca...and_extensions). Utilise donc un char[1024], ajoute un commentaire à l'appel à tgetent, et si on t'en fait le reproche répond que c'est une contrainte de termcap, point barre.

[sben42]

Bonjour,

Petit up pour les questions restées sans réponses..
(Se sera le dernier).

Merci.