lancer une application par un autre tty

Le
Tom
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.
merci

Tom
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
no_spam
Le #1132217
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.

Nicolas George
Le #1132211
no_spam wrote in message Oui. Tu lance ton programme en redirigeant ses entrées sorties:
<mon_programme> >/dev/tty2 2>&1 </dev/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
Le #1437592

no_spam wrote in message Oui. Tu lance ton programme en redirigeant ses entrées sorties:
<mon_programme> >/dev/tty2 2>&1 </dev/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.


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
Le #1132910
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:
<mon_programme> >/dev/tty2 2>&1 </dev/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.



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
Le #1437570
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
Le #1133466
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
Le #1133464
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
Le #1437514
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
Le #1134286
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
Le #1134008
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 :-)



Publicité
Poster une réponse
Anonyme