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"
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Matt écrit:
est ce qu'en mettant "open-x11 xeyes" dans le tcshrc, ca va faire en sorte d'ouvrir x11 en cas de besoin ?
Oui.
ça lance en fait open -a x11 /usr/X11R6/bin/xeyes
à adapter si x11 s'appele xdarwin.
y a pas,
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
open -a x11 /usr/X11R6/bin/xeyes ca ouvres bien x11, mais sans xeyes :-) (alors que si x11 est ouvert, open-x11 xeyes ouvre xeyes)
enfin, apparement c'est censé ouvrir x11 quand on ouvre le terminal, c'est ca ?
j'aurais préféré qqch qui ouvres à la volée x11 si besoin, mais apparement il faut mettre open-x11 devant toutes les commandes qui le necessitent .... tant pis
-- 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"
In article (Dans l'article) <slrncq3uoe.1hgv.lwa@victor.teaser.fr>,
Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Matt <sbehzf@syrius.org> écrit:
est ce qu'en mettant "open-x11 xeyes" dans le tcshrc, ca va faire en
sorte d'ouvrir x11 en cas de besoin ?
Oui.
ça lance en fait
open -a x11 /usr/X11R6/bin/xeyes
à adapter si x11 s'appele xdarwin.
y a pas,
Error: Can't open display: :0.0
(si je le tapes dans le shell)
meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
open -a x11 /usr/X11R6/bin/xeyes
ca ouvres bien x11, mais sans xeyes :-)
(alors que si x11 est ouvert, open-x11 xeyes ouvre xeyes)
enfin,
apparement c'est censé ouvrir x11 quand on ouvre le terminal, c'est ca ?
j'aurais préféré qqch qui ouvres à la volée x11 si besoin,
mais apparement il faut mettre open-x11 devant toutes les commandes qui
le necessitent ....
tant pis
--
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"
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Matt écrit:
est ce qu'en mettant "open-x11 xeyes" dans le tcshrc, ca va faire en sorte d'ouvrir x11 en cas de besoin ?
Oui.
ça lance en fait open -a x11 /usr/X11R6/bin/xeyes
à adapter si x11 s'appele xdarwin.
y a pas,
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
open -a x11 /usr/X11R6/bin/xeyes ca ouvres bien x11, mais sans xeyes :-) (alors que si x11 est ouvert, open-x11 xeyes ouvre xeyes)
enfin, apparement c'est censé ouvrir x11 quand on ouvre le terminal, c'est ca ?
j'aurais préféré qqch qui ouvres à la volée x11 si besoin, mais apparement il faut mettre open-x11 devant toutes les commandes qui le necessitent .... tant pis
-- 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"
lists
Thomas wrote:
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
Il ne faut pas s'attendre à ce que xeyes ouvre X11. Même sous Linux, pour qui X11 est le système de fenêtrage habituel, il faut *démarrer* le serveur X avant de l'utiliser.
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY devrait suffire. En tout cas, je suis sûr que ça marchait, à une époque, chez moi. J'avais testé ça du temps de MacOS X 10.2 ou 10.1, avant la sortie du X11 d'Apple. Ça a peut-être changé...
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Thomas <fantome.forums.tDeContes@free.fr> wrote:
Error: Can't open display: :0.0
(si je le tapes dans le shell)
meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
Il ne faut pas s'attendre à ce que xeyes ouvre X11. Même sous Linux,
pour qui X11 est le système de fenêtrage habituel, il faut *démarrer* le
serveur X avant de l'utiliser.
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY
devrait suffire. En tout cas, je suis sûr que ça marchait, à une époque,
chez moi. J'avais testé ça du temps de MacOS X 10.2 ou 10.1, avant la
sortie du X11 d'Apple. Ça a peut-être changé...
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
Il ne faut pas s'attendre à ce que xeyes ouvre X11. Même sous Linux, pour qui X11 est le système de fenêtrage habituel, il faut *démarrer* le serveur X avant de l'utiliser.
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY devrait suffire. En tout cas, je suis sûr que ça marchait, à une époque, chez moi. J'avais testé ça du temps de MacOS X 10.2 ou 10.1, avant la sortie du X11 d'Apple. Ça a peut-être changé...
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Thomas
In article (Dans l'article) <1gnq1c0.14hu9st12oj134N%, (Julien Salort) wrote (écrivait) :
Thomas wrote:
open-x11 xeyes
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
non, fermé
Il ne faut pas s'attendre à ce que xeyes ouvre X11.
ah, j'ai cru que c'est ce que les autres avaient dit mais je suis pas sur d'avoir bien compris tout ce qu'ils ont dit
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY devrait suffire.
oui, c'est bon, ca marche comme ca :-)
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
(je crois que c'est pour ca qu'ils voulaient me faire utiliser open-x11, mais j'ai du louper des bouts, et peut etre eux aussi :-) )
-- 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"
In article (Dans l'article)
<1gnq1c0.14hu9st12oj134N%lists@juliensalort.org>,
lists@juliensalort.org (Julien Salort) wrote (écrivait) :
Thomas <fantome.forums.tDeContes@free.fr> wrote:
open-x11 xeyes
Error: Can't open display: :0.0
(si je le tapes dans le shell)
meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
non, fermé
Il ne faut pas s'attendre à ce que xeyes ouvre X11.
ah, j'ai cru que c'est ce que les autres avaient dit
mais je suis pas sur d'avoir bien compris tout ce qu'ils ont dit
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY
devrait suffire.
oui, c'est bon, ca marche comme ca :-)
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je
prends le terminal au lieu de xterm, et où je veux ouvrir une app à
distance avec ssh -X, au lieu de l'ouvrir en local
si qqn a une idée ... :-)
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir
parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
(je crois que c'est pour ca qu'ils voulaient me faire utiliser open-x11,
mais j'ai du louper des bouts, et peut etre eux aussi :-) )
--
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"
In article (Dans l'article) <1gnq1c0.14hu9st12oj134N%, (Julien Salort) wrote (écrivait) :
Thomas wrote:
open-x11 xeyes
Error: Can't open display: :0.0 (si je le tapes dans le shell) meme si je commente setenv DISPLAY :0.0 dans le .tcshrc
Tu obtiens cette erreur alors que X11 est ouvert ?
non, fermé
Il ne faut pas s'attendre à ce que xeyes ouvre X11.
ah, j'ai cru que c'est ce que les autres avaient dit mais je suis pas sur d'avoir bien compris tout ce qu'ils ont dit
En supposant que X11 est déjà ouvert. Définir la variable DISPLAY devrait suffire.
oui, c'est bon, ca marche comme ca :-)
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
(je crois que c'est pour ca qu'ils voulaient me faire utiliser open-x11, mais j'ai du louper des bouts, et peut etre eux aussi :-) )
-- 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"
Laurent Wacrenier
Thomas écrit:
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas, ça ne prendra que du swap.
Thomas <fantome.forums.tDeContes@free.fr> écrit:
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je
prends le terminal au lieu de xterm, et où je veux ouvrir une app à
distance avec ssh -X, au lieu de l'ouvrir en local
si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist
et pas dans .bashrc ou je ne sais quoi d'autre ?
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir
parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer
utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY
est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au
démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas,
ça ne prendra que du swap.
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas, ça ne prendra que du swap.
NObertrand.lupartSPAM
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
Si la variable d'environnement DISPLAY est bien renseignée (la même que dans xterm) dans la fenêtre de Terminal.app depuis laquelle tu as fait le "ssh -X", il n'y a pas de raison que celà ne fonctionne pas si ça fonctionne depuis le xterm.
Tu as un message d'erreur?
-- Bertrand
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je
prends le terminal au lieu de xterm, et où je veux ouvrir une app à
distance avec ssh -X, au lieu de l'ouvrir en local
si qqn a une idée ... :-)
Si la variable d'environnement DISPLAY est bien renseignée (la même que
dans xterm) dans la fenêtre de Terminal.app depuis laquelle tu as fait
le "ssh -X", il n'y a pas de raison que celà ne fonctionne pas si ça
fonctionne depuis le xterm.
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
Si la variable d'environnement DISPLAY est bien renseignée (la même que dans xterm) dans la fenêtre de Terminal.app depuis laquelle tu as fait le "ssh -X", il n'y a pas de raison que celà ne fonctionne pas si ça fonctionne depuis le xterm.
Tu as un message d'erreur?
-- Bertrand
Thomas
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas écrit:
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
comment on fait, pour mettre ca dans .MacOS/environement.plist ??
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas, ça ne prendra que du swap.
bon, je crois que je vais opter pour la derniere solution :-) j'ai deja assez de soucis comme ca en ce moment :-) merci :-)
-- 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"
In article (Dans l'article) <slrncq8thg.136g.lwa@victor.teaser.fr>,
Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas <fantome.forums.tDeContes@free.fr> écrit:
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je
prends le terminal au lieu de xterm, et où je veux ouvrir une app à
distance avec ssh -X, au lieu de l'ouvrir en local
si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist
et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc
je savais pas qu'il y avait qqch d'important à ce niveau là :-/
comment on fait, pour mettre ca dans .MacOS/environement.plist ??
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir
parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer
utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY
est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au
démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas,
ça ne prendra que du swap.
bon, je crois que je vais opter pour la derniere solution :-) j'ai deja
assez de soucis comme ca en ce moment :-)
merci :-)
--
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"
In article (Dans l'article) , Laurent Wacrenier <lwa@ teaser . fr> wrote (écrivait) :
Thomas écrit:
enfin, y a encore 1 cas sur 4 où ca ne marche pas, c'est le cas où je prends le terminal au lieu de xterm, et où je veux ouvrir une app à distance avec ssh -X, au lieu de l'ouvrir en local si qqn a une idée ... :-)
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
comment on fait, pour mettre ca dans .MacOS/environement.plist ??
sinon, le mieux du mieux, ca serait, effectivement, de pouvoir parametrer le terminal pour qu'il ouvre automatiquement x11 si necessaire
mais apparement c'est pas possible ... tant pis, on s'en passera :-)
C'est au shell de le faire.
Tu peux regarder avec otool sur l'application que tu veux lancer utilise la librairie X11 et lui faire lancer le serveur si le DISPLAY est local.
C'est peut être possible d'utiliser un wrapper à la librairie.
Mais bon, c'est bien compliqué quand il suffit de lancer X11 au démarrage ou de laisser l'icône dans le dock. Si on ne s'en sert pas, ça ne prendra que du swap.
bon, je crois que je vais opter pour la derniere solution :-) j'ai deja assez de soucis comme ca en ce moment :-) merci :-)
-- 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"
Laurent Wacrenier
Thomas écrit:
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit être posé à l'ouverture de le console.
Thomas <fantome.forums.tDeContes@free.fr> écrit:
DISPLAY est bien défini dans .MacOS/environement.plist
et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc
je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit
être posé à l'ouverture de le console.
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit être posé à l'ouverture de le console.
NObertrand.lupartSPAM
Laurent Wacrenier wrote:
Thomas écrit:
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit être posé à l'ouverture de le console.
~/.tcshrc est toujours executé, sauf si tcsh est invoqué avec "-f", donc les deux fonctionnent.
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
-- Bertrand
Laurent Wacrenier <lwa@teaser.fr> wrote:
Thomas <fantome.forums.tDeContes@free.fr> écrit:
DISPLAY est bien défini dans .MacOS/environement.plist
et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc
je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit
être posé à l'ouverture de le console.
~/.tcshrc est toujours executé, sauf si tcsh est invoqué avec "-f", donc
les deux fonctionnent.
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans
.MacOSX/environment.plist plutôt que dans les fichiers rc est dans le
cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr
que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis
X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
DISPLAY est bien défini dans .MacOS/environement.plist et pas dans .bashrc ou je ne sais quoi d'autre ?
euh, non, dans .tcshrc je savais pas qu'il y avait qqch d'important à ce niveau là :-/
.tcshrc est executué à chaque shell interractif alors que DISPLAY doit être posé à l'ouverture de le console.
~/.tcshrc est toujours executé, sauf si tcsh est invoqué avec "-f", donc les deux fonctionnent.
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
-- Bertrand
Laurent Wacrenier
Bertrand LUPART écrit:
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans
.MacOSX/environment.plist plutôt que dans les fichiers rc est dans le
cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr
que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis
X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance
X11.app, c'est le même DISPLAY qui est utilisé ?
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
Je n'ai pas essayé avec plusieurs utilisateurs, mais si chacun lance X11.app, c'est le même DISPLAY qui est utilisé ?
NObertrand.lupartSPAM
Laurent Wacrenier wrote:
Bertrand LUPART écrit:
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
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 pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte. En démarrant, le serveur X la redéfinira pour toutes les applis X11, 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...)
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans
.MacOSX/environment.plist plutôt que dans les fichiers rc est dans le
cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr
que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis
X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
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 pour ça que si on définit une variable DISPLAY avant de lancer
X11, on n'est pas sûr qu'elle soit correcte.
En démarrant, le serveur X la redéfinira pour toutes les applis X11,
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...)
L'intérêt qu'il peut y avoir à renseigner DISPLAY dans .MacOSX/environment.plist plutôt que dans les fichiers rc est dans le cas où on lance X11.app avec $DISPLAY en paramètre. Comme ça, on est sûr que l'on a toujours la bonne valeur de DISPLAY partout, dans les applis X11 et Aqua, même si on est plusieurs utilisateurs à utiliser X11.
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 pour ça que si on définit une variable DISPLAY avant de lancer X11, on n'est pas sûr qu'elle soit correcte. En démarrant, le serveur X la redéfinira pour toutes les applis X11, 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...)
