avant d'écrire un bout de code, je voudrais être sûr de ne pas réinventer
la roue. Si le but pratique ne vous intéresse pas, je donne plus bas ma
question. L'idée serait de pouvoir lancer une session de quelque chose
(exemple un shell, mais je pense plutôt à des logiciels de mathématiques)
dans un buffer d'éditeur (en l'occurence VIM). JE SAIS qu'il existe des tas
d'approches pour cela :
- la commande :r! qui trouve très vite ses limites
- des scripts comme vish ou vimsh (le second nécessitant néanmoins
une recompilation de VIM si ce dernier n'a pas été compilé avec
+python)
- un patch comme vim-shell
mais je souhaiterais procéder différemment (notamment car je ne souhaite
pas
me restreindre à VIM).
Voici donc ma QUESTION :
existe-t-il un petit utilitaire dont le fonctionnement serait en gros :
a) on le lance en lui donnant comme argument le nom d'un programme
il lance ledit programme en contrôlant ses stdin/stdout et ouvre
lui-même
un FIFO, puis attends qu'on écrive dessus
b) quand on écrit quelque chose sur le FIFO il la récrit sur le stdin du
programme
(exception faite de commandes éventuelles qui lui seraient
directement
adressées)
c) il "publie" la sortie stdout du programme (éventuellement par le
biais d'un
autre FIFO)
Il s'agit donc d'un programme qui permettrait de maintenir ouverte une
session
en offrant ce "service" aux programmes difficilement compatibles avec cette
approche, une sorte de "gestionnaire de session"
Un truc de ce genre existe-t-il sous Unix ?
Cela vous fait-il penser à quelque chose d'autre ?
La démarche vous semble-t-elle acceptable ?
Seriez-vous intéressés le cas échéant par un programme de ce genre ?
Cordialement,
--
Thomas Baruchel
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Laurent Wacrenier
baruchel écrit:
Voici donc ma QUESTION : existe-t-il un petit utilitaire dont le fonctionnement serait en gros : a) on le lance en lui donnant comme argument le nom d'un programme il lance ledit programme en contrôlant ses stdin/stdout et ouvre lui-même un FIFO, puis attends qu'on écrive dessus b) quand on écrit quelque chose sur le FIFO il la récrit sur le stdin du programme (exception faite de commandes éventuelles qui lui seraient directement adressées) c) il "publie" la sortie stdout du programme (éventuellement par le biais d'un autre FIFO)
Pourquoi ne pas lancer le programme directement, saisir l'entrée standart et regarder ce qu'il en sort ?
baruchel <archaiesteron@laposte.net> écrit:
Voici donc ma QUESTION :
existe-t-il un petit utilitaire dont le fonctionnement serait en gros :
a) on le lance en lui donnant comme argument le nom d'un programme
il lance ledit programme en contrôlant ses stdin/stdout et ouvre
lui-même
un FIFO, puis attends qu'on écrive dessus
b) quand on écrit quelque chose sur le FIFO il la récrit sur le stdin du
programme
(exception faite de commandes éventuelles qui lui seraient
directement
adressées)
c) il "publie" la sortie stdout du programme (éventuellement par le
biais d'un
autre FIFO)
Pourquoi ne pas lancer le programme directement, saisir l'entrée
standart et regarder ce qu'il en sort ?
Voici donc ma QUESTION : existe-t-il un petit utilitaire dont le fonctionnement serait en gros : a) on le lance en lui donnant comme argument le nom d'un programme il lance ledit programme en contrôlant ses stdin/stdout et ouvre lui-même un FIFO, puis attends qu'on écrive dessus b) quand on écrit quelque chose sur le FIFO il la récrit sur le stdin du programme (exception faite de commandes éventuelles qui lui seraient directement adressées) c) il "publie" la sortie stdout du programme (éventuellement par le biais d'un autre FIFO)
Pourquoi ne pas lancer le programme directement, saisir l'entrée standart et regarder ce qu'il en sort ?
Jean-Marc Bourguet
(baruchel) writes:
Voici donc ma QUESTION : existe-t-il un petit utilitaire dont le fonctionnement serait en gros :
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
archaiesteron@laposte.net (baruchel) writes:
Voici donc ma QUESTION :
existe-t-il un petit utilitaire dont le fonctionnement serait en gros :
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Voici donc ma QUESTION : existe-t-il un petit utilitaire dont le fonctionnement serait en gros :
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
archaiesteron
Laurent Wacrenier wrote:
Pourquoi ne pas lancer le programme directement, saisir l'entrée standart et regarder ce qu'il en sort ?
C'est ici la notion de session qui est en jeu : supposes que tu souhaites utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé donc à des macros, notamment associées à la touche entrée). Tu veux DANS ton buffer, lancer une session de calcul. Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer un logiciel de calcul (qui éventuellement peut être configuré pour une sortie en code TeX, mais c'est un autre problème). Suppose que la première ligne envoyée dans le stdin de ton logiciel de calcul soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes d'envoyer cela sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le logiciel va quitter après avoir parcouru cette unique ligne ; en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne "a^2", il faut que le programme reste ouvert entre la première ligne et la seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc :r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
En revanche, suppose que les choses se passent techniquement comme suit :
On lance un programme (celui que je décris) : il forke, et le père termine après avoir retourné le nom d'un FIFO créé. Du coup, mes macros VIM récupèrent ce nom de fichier ; elles savent désormais où écrire. Le père ayant forké puis quitté, VIM a à nouveau la main. Le fils attend qu'on écrive sur le FIFO après avoir lancé le logiciel spécifié (exemple un logiciel de calcul) ; dès qu'on écrit sur le FIFO la première ligne, il la recopie dans le stdin dudit logiciel ; quand on saisit la seconde, il fait de même. L'intérêt est que les résultats peuvent (selon les macros utilisées) s'afficher au fur et à mesure dans ton buffer VIM, ce qui est très pratique en terme d'édition, même si l'auteur de vim refuse (cf. l'aide) pour des raisons également compréhensibles d'inclure cette fonctionalité dans VIM (emacs l'a).
J'espère avoir répondu à ta question.
-- Thomas Baruchel -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Laurent Wacrenier wrote:
Pourquoi ne pas lancer le programme directement, saisir l'entrée
standart et regarder ce qu'il en sort ?
C'est ici la notion de session qui est en jeu : supposes que tu souhaites
utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé
donc à des macros, notamment associées à la touche entrée). Tu veux DANS
ton buffer, lancer une session de calcul.
Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer
un logiciel de calcul (qui éventuellement peut être configuré pour
une sortie en code TeX, mais c'est un autre problème).
Suppose que la première ligne envoyée dans le stdin de ton logiciel de
calcul
soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes
d'envoyer cela
sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le
logiciel va quitter après avoir parcouru cette unique ligne ;
en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne
"a^2", il faut que le programme reste ouvert entre la première ligne et la
seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc
:r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être
ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
En revanche, suppose que les choses se passent techniquement comme suit :
On lance un programme (celui que je décris) : il forke, et le père termine
après avoir retourné le nom d'un FIFO créé. Du coup, mes macros VIM
récupèrent ce nom de fichier ; elles savent désormais où écrire.
Le père ayant forké puis quitté, VIM a à nouveau la main. Le fils
attend qu'on écrive sur le FIFO après avoir lancé le logiciel spécifié
(exemple un logiciel de calcul) ; dès qu'on écrit sur le FIFO la première
ligne,
il la recopie dans le stdin dudit logiciel ; quand on saisit la seconde,
il fait de
même. L'intérêt est que les résultats peuvent (selon les macros utilisées)
s'afficher au fur et à mesure dans ton buffer VIM, ce qui est très
pratique en
terme d'édition, même si l'auteur de vim refuse (cf. l'aide) pour des
raisons
également compréhensibles d'inclure cette fonctionalité dans VIM (emacs
l'a).
J'espère avoir répondu à ta question.
--
Thomas Baruchel
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Pourquoi ne pas lancer le programme directement, saisir l'entrée standart et regarder ce qu'il en sort ?
C'est ici la notion de session qui est en jeu : supposes que tu souhaites utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé donc à des macros, notamment associées à la touche entrée). Tu veux DANS ton buffer, lancer une session de calcul. Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer un logiciel de calcul (qui éventuellement peut être configuré pour une sortie en code TeX, mais c'est un autre problème). Suppose que la première ligne envoyée dans le stdin de ton logiciel de calcul soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes d'envoyer cela sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le logiciel va quitter après avoir parcouru cette unique ligne ; en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne "a^2", il faut que le programme reste ouvert entre la première ligne et la seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc :r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
En revanche, suppose que les choses se passent techniquement comme suit :
On lance un programme (celui que je décris) : il forke, et le père termine après avoir retourné le nom d'un FIFO créé. Du coup, mes macros VIM récupèrent ce nom de fichier ; elles savent désormais où écrire. Le père ayant forké puis quitté, VIM a à nouveau la main. Le fils attend qu'on écrive sur le FIFO après avoir lancé le logiciel spécifié (exemple un logiciel de calcul) ; dès qu'on écrit sur le FIFO la première ligne, il la recopie dans le stdin dudit logiciel ; quand on saisit la seconde, il fait de même. L'intérêt est que les résultats peuvent (selon les macros utilisées) s'afficher au fur et à mesure dans ton buffer VIM, ce qui est très pratique en terme d'édition, même si l'auteur de vim refuse (cf. l'aide) pour des raisons également compréhensibles d'inclure cette fonctionalité dans VIM (emacs l'a).
J'espère avoir répondu à ta question.
-- Thomas Baruchel -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
archaiesteron
Jean-Marc Bourguet wrote:
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
Certes, mais la réponse reste tout de même éclairante ; je vais quand même aller explorer, d'autant que je n'ai jamais utilisé expect jusqu'à présent.
Merci,
-- Thomas Baruchel -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Jean-Marc Bourguet wrote:
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
Certes, mais la réponse reste tout de même éclairante ; je vais quand même
aller explorer, d'autant que je n'ai jamais utilisé expect jusqu'à présent.
Merci,
--
Thomas Baruchel
--
0% de pub! Que du bonheur et des vrais adhérents !
Vous aussi inscrivez-vous sans plus tarder!!
Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Regarde expect. Mais ce n'est pas directement ce que tu demandes.
Certes, mais la réponse reste tout de même éclairante ; je vais quand même aller explorer, d'autant que je n'ai jamais utilisé expect jusqu'à présent.
Merci,
-- Thomas Baruchel -- 0% de pub! Que du bonheur et des vrais adhérents ! Vous aussi inscrivez-vous sans plus tarder!! Message posté à partir de http://www.gyptis.org, BBS actif depuis 1995.
Laurent Wacrenier
baruchel écrit:
C'est ici la notion de session qui est en jeu : supposes que tu souhaites utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé donc à des macros, notamment associées à la touche entrée). Tu veux DANS ton buffer, lancer une session de calcul. Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer un logiciel de calcul (qui éventuellement peut être configuré pour une sortie en code TeX, mais c'est un autre problème). Suppose que la première ligne envoyée dans le stdin de ton logiciel de calcul soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes d'envoyer cela sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le logiciel va quitter après avoir parcouru cette unique ligne ; en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne "a^2", il faut que le programme reste ouvert entre la première ligne et la seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc :r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
Le protocole d'échange est bien pauvre. Celà peut induire des mélanges.
Faire un programme serveur en C lié à l'application via une socket unix anonyme (socketpair(2)) en mode non bloquant (voir fcntl(2)). Il renvoie tout ce que l'application peut écrire tant que celle ci n'est pas en attente de lecture (voir select(2)).
Un utilitaire client discute avec le programme via une socket nommée pour lui envoyer ses instructions et retourner les résultats.
Le serveur se lance au début en tâche de fond, son rôle est de maintenir les descripteurs de fichier de l'application ouverts.
baruchel <archaiesteron@laposte.net> écrit:
C'est ici la notion de session qui est en jeu : supposes que tu souhaites
utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé
donc à des macros, notamment associées à la touche entrée). Tu veux DANS
ton buffer, lancer une session de calcul.
Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer
un logiciel de calcul (qui éventuellement peut être configuré pour
une sortie en code TeX, mais c'est un autre problème).
Suppose que la première ligne envoyée dans le stdin de ton logiciel de
calcul
soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes
d'envoyer cela
sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le
logiciel va quitter après avoir parcouru cette unique ligne ;
en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne
"a^2", il faut que le programme reste ouvert entre la première ligne et la
seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc
:r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être
ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
Le protocole d'échange est bien pauvre. Celà peut induire des
mélanges.
Faire un programme serveur en C lié à l'application via une socket
unix anonyme (socketpair(2)) en mode non bloquant (voir fcntl(2)). Il
renvoie tout ce que l'application peut écrire tant que celle ci n'est
pas en attente de lecture (voir select(2)).
Un utilitaire client discute avec le programme via une socket nommée
pour lui envoyer ses instructions et retourner les résultats.
Le serveur se lance au début en tâche de fond, son rôle est de
maintenir les descripteurs de fichier de l'application ouverts.
C'est ici la notion de session qui est en jeu : supposes que tu souhaites utiliser le programme dans le cadre d'une saisie de texte avec VIM (couplé donc à des macros, notamment associées à la touche entrée). Tu veux DANS ton buffer, lancer une session de calcul. Donc, au milieu de ton document (exemple du code LaTeX), tu vas lancer un logiciel de calcul (qui éventuellement peut être configuré pour une sortie en code TeX, mais c'est un autre problème). Suppose que la première ligne envoyée dans le stdin de ton logiciel de calcul soit "a=5". Tu tapes entrée à la fin de la ligne. Si tu te contentes d'envoyer cela sur l'entrée standard et de récupérer la sortie, tu n'iras pas loin, car le logiciel va quitter après avoir parcouru cette unique ligne ; en revanche, si tu ne tapes cela que dans l'idée d'une deuxième ligne "a^2", il faut que le programme reste ouvert entre la première ligne et la seconde. Avec VIM, c'est impossible :
:r!echo a=5 | bc :r!echo a^2 | bc
n'a strictement aucun sens (deux sessions différentes de bc vont être ouvertes, et la seconde n'aura aucune idée de ce que doit être 'a').
Le protocole d'échange est bien pauvre. Celà peut induire des mélanges.
Faire un programme serveur en C lié à l'application via une socket unix anonyme (socketpair(2)) en mode non bloquant (voir fcntl(2)). Il renvoie tout ce que l'application peut écrire tant que celle ci n'est pas en attente de lecture (voir select(2)).
Un utilitaire client discute avec le programme via une socket nommée pour lui envoyer ses instructions et retourner les résultats.
Le serveur se lance au début en tâche de fond, son rôle est de maintenir les descripteurs de fichier de l'application ouverts.
