Voilà ce que je voudrais faire. J'aimerais lancer une application dans
un certain tty (par exemple le 2, c'est à dire une session texte, en
appuyant sur ctrl-alt-f2) mais que la partie graphique du programme
d'affiche sur une session graphique (sur laquelle je suis connecté
naturellement).
Parce qu'en fait c'est un programme qui affiche du texte dans la console
pendant son exécution mais la fenêtre graphique est en plein ecran et
y'a pas moyen de switcher.
Alors j'aimerais savoir si c'st possible et dans ce cas comment.
merci
Voilà ce que je voudrais faire. J'aimerais lancer une application dans un certain tty (par exemple le 2, c'est à dire une session texte, en appuyant sur ctrl-alt-f2) mais que la partie graphique du programme d'affiche sur une session graphique (sur laquelle je suis connecté naturellement). Parce qu'en fait c'est un programme qui affiche du texte dans la console pendant son exécution mais la fenêtre graphique est en plein ecran et y'a pas moyen de switcher.
Alors j'aimerais savoir si c'st possible et dans ce cas comment.
Oui. Tu lance ton programme en redirigeant ses entrées sorties: <mon_programme> >/dev/tty2 2>&1 </dev/tty2 Et ça marche nickel.
On Mon, 23 Aug 2004 20:41:25 +0200, Tom wrote:
Bonjour
Voilà ce que je voudrais faire. J'aimerais lancer une application dans
un certain tty (par exemple le 2, c'est à dire une session texte, en
appuyant sur ctrl-alt-f2) mais que la partie graphique du programme
d'affiche sur une session graphique (sur laquelle je suis connecté
naturellement).
Parce qu'en fait c'est un programme qui affiche du texte dans la console
pendant son exécution mais la fenêtre graphique est en plein ecran et
y'a pas moyen de switcher.
Alors j'aimerais savoir si c'st possible et dans ce cas comment.
Oui. Tu lance ton programme en redirigeant ses entrées sorties:
<mon_programme> >/dev/tty2 2>&1 </dev/tty2
Et ça marche nickel.
Voilà ce que je voudrais faire. J'aimerais lancer une application dans un certain tty (par exemple le 2, c'est à dire une session texte, en appuyant sur ctrl-alt-f2) mais que la partie graphique du programme d'affiche sur une session graphique (sur laquelle je suis connecté naturellement). Parce qu'en fait c'est un programme qui affiche du texte dans la console pendant son exécution mais la fenêtre graphique est en plein ecran et y'a pas moyen de switcher.
Alors j'aimerais savoir si c'st possible et dans ce cas comment.
Oui. Tu lance ton programme en redirigeant ses entrées sorties: <mon_programme> >/dev/tty2 2>&1 </dev/tty2 Et ça marche nickel.
Nicolas George
no_spam wrote in message : Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
no_spam wrote in message <pan.2004.08.23.20.43.01.483754@magic.fr>:
Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le
programme naturellement présent dans tty2 ne lit pas sur le clavier, par
exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même
comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^)
depuis tty2.
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Marc Mezzarobba
no_spam wrote in message : Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Si je comprends bien (ie, si la « session graphique », c'est une session X), il y a moyen d'éviter ce problème en lançant le programme depuis le terminal, avec une commande du genre xcalc -display :0
-- Marc Mezzarobba Pour enregistrer mon adresse, ou si ne fonctionne pas, remplacez « mm » par « marc ».
no_spam wrote in message <pan.2004.08.23.20.43.01.483754@magic.fr>:
Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le
programme naturellement présent dans tty2 ne lit pas sur le clavier, par
exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même
comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^)
depuis tty2.
Si je comprends bien (ie, si la « session graphique », c'est une session X),
il y a moyen d'éviter ce problème en lançant le programme depuis le
terminal, avec une commande du genre
xcalc -display :0
--
Marc Mezzarobba
Pour enregistrer mon adresse, ou si mm@mezzarobba.net ne fonctionne pas,
remplacez « mm » par « marc ».
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre. De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Si je comprends bien (ie, si la « session graphique », c'est une session X), il y a moyen d'éviter ce problème en lançant le programme depuis le terminal, avec une commande du genre xcalc -display :0
-- Marc Mezzarobba Pour enregistrer mon adresse, ou si ne fonctionne pas, remplacez « mm » par « marc ».
no_spam
On Tue, 24 Aug 2004 08:55:07 +0200, Marc Mezzarobba wrote:
no_spam wrote in message : Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre.
J'utilise généralement un terminal "vierge" pour ce genre de choses... Sinon, ça ne marche effectivement pas correctement.
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Là, je ne vois pas la raison....
Si je comprends bien (ie, si la « session graphique », c'est une session X), il y a moyen d'éviter ce problème en lançant le programme depuis le terminal, avec une commande du genre xcalc -display :0
C'est une autre solution, pas toujours praticable... En fait, j'utilise celà plus souvent pour des programmes frame-buffer. Je n'ai qu'une console ouverte, je lance mon programme en le redirigeant vers un autre tty, tandis que la console se fait "bouffer" par le programme en fb...
On Tue, 24 Aug 2004 08:55:07 +0200, Marc Mezzarobba wrote:
no_spam wrote in message <pan.2004.08.23.20.43.01.483754@magic.fr>:
Oui. Tu lance ton programme en redirigeant ses entrées sorties:
Cette partie-là peut poser problème. Il faut également s'assurer que le
programme naturellement présent dans tty2 ne lit pas sur le clavier, par
exemple en lançant un sleep 10000 ou quelque chose du genre.
J'utilise généralement un terminal "vierge" pour ce genre de choses...
Sinon, ça ne marche effectivement pas correctement.
De plus, même
comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^)
depuis tty2.
Là, je ne vois pas la raison....
Si je comprends bien (ie, si la « session graphique », c'est une session X),
il y a moyen d'éviter ce problème en lançant le programme depuis le
terminal, avec une commande du genre
xcalc -display :0
C'est une autre solution, pas toujours praticable... En fait, j'utilise
celà plus souvent pour des programmes frame-buffer. Je n'ai qu'une
console ouverte, je lance mon programme en le redirigeant vers un autre
tty, tandis que la console se fait "bouffer" par le programme en fb...
Cette partie-là peut poser problème. Il faut également s'assurer que le programme naturellement présent dans tty2 ne lit pas sur le clavier, par exemple en lançant un sleep 10000 ou quelque chose du genre.
J'utilise généralement un terminal "vierge" pour ce genre de choses... Sinon, ça ne marche effectivement pas correctement.
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Là, je ne vois pas la raison....
Si je comprends bien (ie, si la « session graphique », c'est une session X), il y a moyen d'éviter ce problème en lançant le programme depuis le terminal, avec une commande du genre xcalc -display :0
C'est une autre solution, pas toujours praticable... En fait, j'utilise celà plus souvent pour des programmes frame-buffer. Je n'ai qu'une console ouverte, je lance mon programme en le redirigeant vers un autre tty, tandis que la console se fait "bouffer" par le programme en fb...
Nicolas George
no_spam wrote in message :
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux correspondant à ^C et compagnie, et qui ne se change pas simplement par une redirection des entrées/sorties standard. Il faut un appel système pour ça (setsid), et il n'est possible d'acquérir un terminal comme terminal de contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
à condition qu'il n'y ait personne déjà sur tty8, et si la version particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY (dash et bash ne le font pas, zsh le fait).
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il faut voir comment elle interagit avec le framebuffer.
no_spam wrote in message <pan.2004.08.24.23.49.22.212109@magic.fr>:
De plus, même
comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^)
depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux
correspondant à ^C et compagnie, et qui ne se change pas simplement par une
redirection des entrées/sorties standard. Il faut un appel système pour ça
(setsid), et il n'est possible d'acquérir un terminal comme terminal de
contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la
commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
à condition qu'il n'y ait personne déjà sur tty8, et si la version
particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY
(dash et bash ne le font pas, zsh le fait).
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il
faut voir comment elle interagit avec le framebuffer.
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux correspondant à ^C et compagnie, et qui ne se change pas simplement par une redirection des entrées/sorties standard. Il faut un appel système pour ça (setsid), et il n'est possible d'acquérir un terminal comme terminal de contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
à condition qu'il n'y ait personne déjà sur tty8, et si la version particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY (dash et bash ne le font pas, zsh le fait).
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il faut voir comment elle interagit avec le framebuffer.
no_spam
On Wed, 25 Aug 2004 00:22:56 +0000, Nicolas George wrote:
no_spam wrote in message :
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux correspondant à ^C et compagnie, et qui ne se change pas simplement par une redirection des entrées/sorties standard. Il faut un appel système pour ça (setsid), et il n'est possible d'acquérir un terminal comme terminal de contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
Pourquoi le sh -c ?
à condition qu'il n'y ait personne déjà sur tty8, et si la version particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY (dash et bash ne le font pas, zsh le fait).
OK, je vois, je savais que setsid détachait le process de son terminal de controle. Je n'avais pas vu l'effet de bord qui en fait le process de controle du terminal sur lequel il est, si celui ci n'en a pas.
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il faut voir comment elle interagit avec le framebuffer.
Le framebuffer interragit très mal avec les tty... Généralement, il vaut mieux que ce soit le programme qui se sert du frame-buffer qui recherche de lui même un tty libre pour se lancer. Mais la plupart des programmes se contentent de se lancer dans le tty courant... Si l'entrée et la sortie standard ne sont pas redirigés, le résultat est souvent catastrophique...
On Wed, 25 Aug 2004 00:22:56 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.08.24.23.49.22.212109@magic.fr>:
De plus, même
comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^)
depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux
correspondant à ^C et compagnie, et qui ne se change pas simplement par une
redirection des entrées/sorties standard. Il faut un appel système pour ça
(setsid), et il n'est possible d'acquérir un terminal comme terminal de
contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la
commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
Pourquoi le sh -c ?
à condition qu'il n'y ait personne déjà sur tty8, et si la version
particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY
(dash et bash ne le font pas, zsh le fait).
OK, je vois, je savais que setsid détachait le process de son terminal de
controle. Je n'avais pas vu l'effet de bord qui en fait le process de
controle du terminal sur lequel il est, si celui ci n'en a pas.
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il
faut voir comment elle interagit avec le framebuffer.
Le framebuffer interragit très mal avec les tty...
Généralement, il vaut mieux que ce soit le programme qui se sert du
frame-buffer qui recherche de lui même un tty libre pour se lancer.
Mais la plupart des programmes se contentent de se lancer dans le tty
courant... Si l'entrée et la sortie standard ne sont pas redirigés, le
résultat est souvent catastrophique...
On Wed, 25 Aug 2004 00:22:56 +0000, Nicolas George wrote:
no_spam wrote in message :
De plus, même comme ça, le programme ne recevra pas les signaux du terminal (^C, ^Z, ^) depuis tty2.
Un processus a un « terminal de contrôle », duquel il reçoit les signaux correspondant à ^C et compagnie, et qui ne se change pas simplement par une redirection des entrées/sorties standard. Il faut un appel système pour ça (setsid), et il n'est possible d'acquérir un terminal comme terminal de contrôle que s'il n'y a pas déjà de processus dessus. Il se peut que la commande suivante fonctionne :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
Pourquoi le sh -c ?
à condition qu'il n'y ait personne déjà sur tty8, et si la version particulière utilisée comme sh ne fait pas ses redirections avec O_NOCTTY (dash et bash ne le font pas, zsh le fait).
OK, je vois, je savais que setsid détachait le process de son terminal de controle. Je n'avais pas vu l'effet de bord qui en fait le process de controle du terminal sur lequel il est, si celui ci n'en a pas.
Il y a la commande open qui sert à faire tout ça proprement d'un coup. Il faut voir comment elle interagit avec le framebuffer.
Le framebuffer interragit très mal avec les tty... Généralement, il vaut mieux que ce soit le programme qui se sert du frame-buffer qui recherche de lui même un tty libre pour se lancer. Mais la plupart des programmes se contentent de se lancer dans le tty courant... Si l'entrée et la sortie standard ne sont pas redirigés, le résultat est souvent catastrophique...
Nicolas George
no_spam wrote in message :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1" Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid. C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle qui attache un processus (sauf si l'ouverture se fait avec l'option O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des redirections.
Mais utiliser open est certainement plus fiable.
no_spam wrote in message <pan.2004.08.25.21.53.41.434285@magic.fr>:
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid.
C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle
qui attache un processus (sauf si l'ouverture se fait avec l'option
O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des
redirections.
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1" Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid. C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle qui attache un processus (sauf si l'ouverture se fait avec l'option O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des redirections.
Mais utiliser open est certainement plus fiable.
no_spam
On Wed, 25 Aug 2004 22:34:49 +0000, Nicolas George wrote:
no_spam wrote in message :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1" Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid. C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle qui attache un processus (sauf si l'ouverture se fait avec l'option O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des redirections.
D'accord, je vois.
Mais utiliser open est certainement plus fiable.
... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
On Wed, 25 Aug 2004 22:34:49 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.08.25.21.53.41.434285@magic.fr>:
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1"
Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid.
C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle
qui attache un processus (sauf si l'ouverture se fait avec l'option
O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des
redirections.
D'accord, je vois.
Mais utiliser open est certainement plus fiable.
... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
On Wed, 25 Aug 2004 22:34:49 +0000, Nicolas George wrote:
no_spam wrote in message :
setsid sh -c "exec foobar </dev/tty8 >/dev/tty8 2>&1" Pourquoi le sh -c ?
Si on écrit simplement
setsid foobar </dev/tty8 >/dev/tty8 2>&1
alors les redirections sont faites par le shell avant l'appel de setsid. C'est le fait d'ouvrir un terminal quand on n'a pas de terminal de contrôle qui attache un processus (sauf si l'ouverture se fait avec l'option O_NOCTTY. Il faut donc que le setsid soit fait avant au moins l'une des redirections.
D'accord, je vois.
Mais utiliser open est certainement plus fiable.
... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Nicolas George
no_spam wrote in message :
Mais utiliser open est certainement plus fiable. ... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
no_spam wrote in message <pan.2004.08.26.06.52.26.387101@magic.fr>:
Mais utiliser open est certainement plus fiable.
... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
Mais utiliser open est certainement plus fiable. ... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
no_spam
On Thu, 26 Aug 2004 15:29:21 +0000, Nicolas George wrote:
no_spam wrote in message :
Mais utiliser open est certainement plus fiable. ... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
Je n'ai pas cette commande. Habituellement, c'est plutôt *getty pour faire celà, non ? J'ai relu les mans de ces joyeusetés pour me raffraichir un peu la mémoire, ça ne fait jamais de mal :-)
On Thu, 26 Aug 2004 15:29:21 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.08.26.06.52.26.387101@magic.fr>:
Mais utiliser open est certainement plus fiable.
... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
Je n'ai pas cette commande. Habituellement, c'est plutôt *getty pour
faire celà, non ? J'ai relu les mans de ces joyeusetés pour me
raffraichir un peu la mémoire, ça ne fait jamais de mal :-)
On Thu, 26 Aug 2004 15:29:21 +0000, Nicolas George wrote:
no_spam wrote in message :
Mais utiliser open est certainement plus fiable. ... si on a la maitrise du code et qu'on a envie d'y mettre les mains :-)
Je parle de la commande open :
open (1) - start a program on a new virtual terminal (VT).
Je n'ai pas cette commande. Habituellement, c'est plutôt *getty pour faire celà, non ? J'ai relu les mans de ces joyeusetés pour me raffraichir un peu la mémoire, ça ne fait jamais de mal :-)
