dans ma config actuelle, je peux lancer des apps gtk en tapant leur nom
dans un xterm x11, mais pas dans le terminal
y a t il un moyen de configurer le terminal en sorte qu'il connaisses
x11, ou pas du tout ?
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
Je n'ai pas essayé, mais ce ne me semble pas possible : si chaque utilisateur lance un serveur X, chacun doit avoir son propre port. Donc le display est différent pour chacun des instances. Ou alors il y a une astuce que j'ai loupé.
-- McA> C'est pas des injures ça?? JJS> Fu2. McA> Tiens encore une fois et c'est toi qui parle d'injures!! -+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
Salut Laurent, Salut la foule,
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance
X11.app, c'est le même DISPLAY qui est utilisé ?
Je n'ai pas essayé, mais ce ne me semble pas possible : si chaque
utilisateur lance un serveur X, chacun doit avoir son propre port.
Donc le display est différent pour chacun des instances. Ou alors il y
a une astuce que j'ai loupé.
--
McA> C'est pas des injures ça??
JJS> Fu2.
McA> Tiens encore une fois et c'est toi qui parle d'injures!!
-+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
Je n'ai pas essayé, mais ce ne me semble pas possible : si chaque utilisateur lance un serveur X, chacun doit avoir son propre port. Donc le display est différent pour chacun des instances. Ou alors il y a une astuce que j'ai loupé.
-- McA> C'est pas des injures ça?? JJS> Fu2. McA> Tiens encore une fois et c'est toi qui parle d'injures!! -+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
Laurent Wacrenier
Bertrand LUPART écrit:
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
Non, chacun a le sien.
C'est bien ce que je me disais.
C'est pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
donc on est sûr d'avoir le bon DISPLAY avec xterm. Mais ce n'est pas le cas avec Terminal.app.
Ce qui serait pas mal, ce serait un hack qui permettrait de toujours lancer X11.app avec $DISPLAY en paramètre. On peut faire un wrapper, mais après il faut s'arranger pour toujours passer par lui (open-x11, double-clic sur un fichier OpenOffice...)
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un fichier et faire lire ce fichier avant chaque prompt aux shells du terminal. Faire attentions aux gus qui lancent et quittent X11 notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la socket de X11, en chercher une qui appartient à l'utilisateur et mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et trouver un DISPLAY local.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance
X11.app, c'est le même DISPLAY qui est utilisé ?
Non, chacun a le sien.
C'est bien ce que je me disais.
C'est pour ça que si on définit une variable DISPLAY avant de lancer
X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
donc on est sûr d'avoir le bon DISPLAY avec xterm. Mais ce n'est pas le
cas avec Terminal.app.
Ce qui serait pas mal, ce serait un hack qui permettrait de toujours
lancer X11.app avec $DISPLAY en paramètre.
On peut faire un wrapper, mais après il faut s'arranger pour toujours
passer par lui (open-x11, double-clic sur un fichier OpenOffice...)
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un
fichier et faire lire ce fichier avant chaque prompt aux shells du
terminal. Faire attentions aux gus qui lancent et quittent X11
notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la
socket de X11, en chercher une qui appartient à l'utilisateur et
mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la
socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et
trouver un DISPLAY local.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY)
n'existait pas et où il fallait deviner quel était le bon DISPLAY en
fonction de la machine d'où on venait à partir de commandes qui en
trafiquait les noms. Le tout avec des terminaux X, pour plus de sport
et avec en bonus l'édition du .Xauthority.
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
Non, chacun a le sien.
C'est bien ce que je me disais.
C'est pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
donc on est sûr d'avoir le bon DISPLAY avec xterm. Mais ce n'est pas le cas avec Terminal.app.
Ce qui serait pas mal, ce serait un hack qui permettrait de toujours lancer X11.app avec $DISPLAY en paramètre. On peut faire un wrapper, mais après il faut s'arranger pour toujours passer par lui (open-x11, double-clic sur un fichier OpenOffice...)
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un fichier et faire lire ce fichier avant chaque prompt aux shells du terminal. Faire attentions aux gus qui lancent et quittent X11 notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la socket de X11, en chercher une qui appartient à l'utilisateur et mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et trouver un DISPLAY local.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
NObertrand.lupartSPAM
C'est pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
Oui bien sûr.
En fait, le serveur X se moque totalement que la variable DISPLAY soit renseignée ou non au moment où il est démarré. Si on ne lui demande pas de prendre un port particulier (qu'on lui passe en paramètre), il prend le premier port disponible et renseigne la variable d'environnement DISPLAY...
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
... dont la valeur sera accessible pour tous ses processus fils.
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un fichier et faire lire ce fichier avant chaque prompt aux shells du terminal. Faire attentions aux gus qui lancent et quittent X11 notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la socket de X11, en chercher une qui appartient à l'utilisateur et mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et trouver un DISPLAY local.
Il y a des trucs comme ça sur macosxhints, mais ça ne résoud pas le problème si DISPLAY change au cours de l'utilisation de l'appli quartz (redémarrage de X11), ni le problème des applis quartz qui ne sont pas des shells (lanceur de OpenOffice par exemple)
J'aime bien l'idée de "réserver" un DISPLAY pour chaque utilisateur au moment où il ouvre une session quartz, et forcer le serveur X à l'utiliser, même si avoir une variable DISPLAY renseignée alors qu'aucun serveur X n'est lancé ne doit pas être très correct.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
Comment fonctionne quartz à ce niveau-là? Il doit aussi avoir un système similaire pour gérer l'affichage sur plusieurs écrans.
-- Bertrand
C'est pour ça que si on définit une variable DISPLAY avant de lancer
X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
Oui bien sûr.
En fait, le serveur X se moque totalement que la variable DISPLAY soit
renseignée ou non au moment où il est démarré. Si on ne lui demande pas
de prendre un port particulier (qu'on lui passe en paramètre), il prend
le premier port disponible et renseigne la variable d'environnement
DISPLAY...
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
... dont la valeur sera accessible pour tous ses processus fils.
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un
fichier et faire lire ce fichier avant chaque prompt aux shells du
terminal. Faire attentions aux gus qui lancent et quittent X11
notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la
socket de X11, en chercher une qui appartient à l'utilisateur et
mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la
socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et
trouver un DISPLAY local.
Il y a des trucs comme ça sur macosxhints, mais ça ne résoud pas le
problème si DISPLAY change au cours de l'utilisation de l'appli quartz
(redémarrage de X11), ni le problème des applis quartz qui ne sont pas
des shells (lanceur de OpenOffice par exemple)
J'aime bien l'idée de "réserver" un DISPLAY pour chaque utilisateur au
moment où il ouvre une session quartz, et forcer le serveur X à
l'utiliser, même si avoir une variable DISPLAY renseignée alors qu'aucun
serveur X n'est lancé ne doit pas être très correct.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY)
n'existait pas et où il fallait deviner quel était le bon DISPLAY en
fonction de la machine d'où on venait à partir de commandes qui en
trafiquait les noms. Le tout avec des terminaux X, pour plus de sport
et avec en bonus l'édition du .Xauthority.
Comment fonctionne quartz à ce niveau-là? Il doit aussi avoir un système
similaire pour gérer l'affichage sur plusieurs écrans.
C'est pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte.
Ça se lance quand même ? X11.app attribue tout seul un DISPLAY ?
Oui bien sûr.
En fait, le serveur X se moque totalement que la variable DISPLAY soit renseignée ou non au moment où il est démarré. Si on ne lui demande pas de prendre un port particulier (qu'on lui passe en paramètre), il prend le premier port disponible et renseigne la variable d'environnement DISPLAY...
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
... pour toutes les applis lancées depuis .xinitrc.
... dont la valeur sera accessible pour tous ses processus fils.
Ajouter une application dans .xinitrc qui dépose le DISPLAY dans un fichier et faire lire ce fichier avant chaque prompt aux shells du terminal. Faire attentions aux gus qui lancent et quittent X11 notement sur plusieurs DISPLAY.
Sinon, il y a peut être quelque chose à faire en lisant la date de la socket de X11, en chercher une qui appartient à l'utilisateur et mettre DISPLAY en fonction (le nom du DISPLAY se déduit du nom de la socket).
On peut aussi lire le fichier .Xauthority (avec "xauth list") et trouver un DISPLAY local.
Il y a des trucs comme ça sur macosxhints, mais ça ne résoud pas le problème si DISPLAY change au cours de l'utilisation de l'appli quartz (redémarrage de X11), ni le problème des applis quartz qui ne sont pas des shells (lanceur de OpenOffice par exemple)
J'aime bien l'idée de "réserver" un DISPLAY pour chaque utilisateur au moment où il ouvre une session quartz, et forcer le serveur X à l'utiliser, même si avoir une variable DISPLAY renseignée alors qu'aucun serveur X n'est lancé ne doit pas être très correct.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
Comment fonctionne quartz à ce niveau-là? Il doit aussi avoir un système similaire pour gérer l'affichage sur plusieurs écrans.
-- Bertrand
DINH Viêt Hoà
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur NFS dans lequel était écrit le nom du display (incluant le nom de machine). Je crois qu'il existe aussi des astuces à base de variables d'environnement TERM (qui est hérité au travers du rsh).
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY)
n'existait pas et où il fallait deviner quel était le bon DISPLAY en
fonction de la machine d'où on venait à partir de commandes qui en
trafiquait les noms. Le tout avec des terminaux X, pour plus de sport
et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur
NFS dans lequel était écrit le nom du display (incluant le nom de
machine). Je crois qu'il existe aussi des astuces à base de variables
d'environnement TERM (qui est hérité au travers du rsh).
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur NFS dans lequel était écrit le nom du display (incluant le nom de machine). Je crois qu'il existe aussi des astuces à base de variables d'environnement TERM (qui est hérité au travers du rsh).
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
Laurent Wacrenier
DINH Viêt Hoà écrit:
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur NFS dans lequel était écrit le nom du display (incluant le nom de machine). Je crois qu'il existe aussi des astuces à base de variables d'environnement TERM (qui est hérité au travers du rsh).
Ça s'était fini par reféfinir une touche sur xterm qui lançait la commande shell qui va bien.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY)
n'existait pas et où il fallait deviner quel était le bon DISPLAY en
fonction de la machine d'où on venait à partir de commandes qui en
trafiquait les noms. Le tout avec des terminaux X, pour plus de sport
et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur
NFS dans lequel était écrit le nom du display (incluant le nom de
machine). Je crois qu'il existe aussi des astuces à base de variables
d'environnement TERM (qui est hérité au travers du rsh).
Ça s'était fini par reféfinir une touche sur xterm qui lançait la
commande shell qui va bien.
Ça me rappelle le bon vieux temps où ssh (qui exporte DISPLAY) n'existait pas et où il fallait deviner quel était le bon DISPLAY en fonction de la machine d'où on venait à partir de commandes qui en trafiquait les noms. Le tout avec des terminaux X, pour plus de sport et avec en bonus l'édition du .Xauthority.
ah ouais ? dans ma bonne vieille école, c'était à coup de fichier sur NFS dans lequel était écrit le nom du display (incluant le nom de machine). Je crois qu'il existe aussi des astuces à base de variables d'environnement TERM (qui est hérité au travers du rsh).
Ça s'était fini par reféfinir une touche sur xterm qui lançait la commande shell qui va bien.
