En graphique (gnome/sawfish) si je lance un xterm, su vers root et que j'essaye de lancer emacs (mais je suppose que c'est la meme chose pour toute appli graphique) j'obtiens :
 

 
Il y a moyen de ne pas avoir a revenir a un tty (c'est penible) pour pouvoir editer un fichier de config en root depuis un bureau ?
 

vi (non c'est horrible comme prise en main: pico ou nano ou autre éditeur)

Oui mais non   Le probleme n'est pas tant emacs que d'arriver a lancer une appli graphique en root (si c'est possible). Au pire il y a toujours nano

man xhost

La legendaire amabilite du linuxien    
 
Il ne t'es pas venu a l'esprit qu'etant donne que xhost est mentionne dans le message d'erreur je suis alle voir par la, et que peut-etre eventuellement j'ai fais les ajustements necessaires avant de demander ?

alors dis ce que tu as fais
 
P.S. je n'utilise pas linux

La légendaire amabilité du BSDien...

en root (sous csh p.ex.):
setenv DISPLAY :0.0
 
en user si ca ne marche toujours pas utilise xhost

Et bien un truc du genre  

Mais ca ne change rien    
 
(bon, aussi faut dire que j'ai pas redemmare le serveur x)

 
Tu serais etonne, mail n'importe quel port maintainer et tu auras une reponse tres rapide a ta question. (jamais vu ca avec linux )

Sinon comprenez bien que je ne cherche pas tant a resoudre le probleme (que je peux contourner avec nano par exemple) qu'a comprendre ce qui coince.

Alt-Ctrl-Backspace pour redémarrer le serveur X (mais tu le sais pitêtre déjà)

 
pas besoin de redemarrer X.  

 
pourquoi redemarrer X ?
 
 

emacs -nw

logiquement :
 
- tu lances un terminal
- en tant qu'utilisateur à qui appartient la session graphique (donc le user par defaut dans le terminal) tu fais xhost +
- "su" pour passer root
- export DISPLAY=":0.0" (a adapter si jamais tu es sur un autre display)
 
et là ca doit marcher, en tout cas ca marche chez tout le monde comme ça

je dis pas qu'il faut le faire, je dis comment le faire.

 
NON NON NON !
 
xhost + desactive completement l'access control a X (man xhost )
 
et pour le DISPLAY : le mettre dans .bashrc .cshrc ou autres

Donc si je comprends bien, pour pouvoir lancer une appli graphique en root, je fais de l'export display (un peu comme si je me loggai depuis un autre poste en reseau). J'ai bon ?

emacs -nw ne fonctionne pas ?

J'avais pas essaye    
Ca marche impec, mais en mode texte   C'est pas le probleme.

j'ai pas lu tout le thread en entier mais tu voulais un emacs à partir d'un term non ? Il est dedans ça change quoi ?

Non, ce que je veux c'est comprendre pourquoi root ne peut pas lancer une appli graphique depuis un xterm ?

et  

tout court ?

 
on va se calmer hein
 
evidemment que xhost + est un peu brutal, mais ca permet de tester, deja...
 
quand au DISPLAY dans le .bashrc, c'est pas terrible.
1- il faut construire une vraie variable DISPLAY, parce que suivant le nombre de serveurs X qui tournent et le nombre d'ecrans que tu as, ca sera pas toujours :0.0
2- il faut que le .bashrc soit lu si tu fait "su" ou "su -" c'est pas pareil

 
de maniere generale, quand tu utilises avec un utilisateur A le bureau  créé par l'utilisateur B, tu fais presque de l'export display, oui
 
la nuance c'est que là, l'affichage n'est pas deporté puisque tu reste sur ta machine, mais tu utilises des commandes qui font la même chose

 
Oui c'est brutal, mais dis alors que c'est pour tester histoire que certains ne pensent pas que c'est comme ca qu'il faut faire.
 
sinon :
 
1) rien ne t'empeche d'avoir une entree par defaut pour ton DISPLAY dans ton .shellrc mais bon je te l'accorde (ceci dit, un su n'est pas sense effacer le DISPLAY courrant si c'est le cas c'est que probablement un su - a ete fait)
 
2) a ce que je sache su et su - lisent tous les deux le .shellrc (je mets .shellrc car il faut mettre dans le rc correspondant au shell indique par /etc/passwd )

seul "su -" est un shell de connexion (ou "su -l" ou "su --login" )
 
sans le shell de connexion, la variable SHELL est positionnée avec le nom seul du shell du user dont on prend l'identité.
 
Or, theoriquement, pour qu'un shell lise ses fichiers de démarrage, il faut que SHELL soit positionnée à "bash-" ou "csh-" par exemple, ce que fait l'option login (en plus du positionnement de repertoire, et d'autres variables d'environnement)
 
man su , paragraphe sur l'option "-"
 

 
1) oui tout a fait
 
2) tu veux en venir ou ?  
 
(pour le man je l'ai lu merci)

je crois que le monsieur devrais taper :

 
dans un xterm avec son user avant de taper:

pour passer root.
 
et voilà  

Bon, c'est marrant comme certains semblent avoir du mal a cerner le probleme :  
 
je n'ai pas BESOIN d'une solution, mais de COMPRENDRE ce qui coince, vu que j'ai une solution alternative. Une fois que j'aurai compris ou ca bloque j'essairai par moi meme de trouver une solution.  
 
@nikosaka : ca marche

 
au fait que le ".shellrc" ne sera lu qu'avec "su -"  
 
sinon, pour le probleme de depart, essaie de lancer just xhost pour voir la difference entre "xhost +", "xhost +root" et "xhost +local:root", tu aura peut etre ta reponse

Je l'ai eu, merci Mais que la discussion sur les su continue, elle est instructive.

 
J'ai un user test utilisant sh, et root utilise csh. Que test fasse su ou su - /root/.cshrc est bel et bien lu.
 
une fois la variable SHELL positionnee par su, le shell est lance et c'est ce dernier qui va lire son fichier de config (.shrc pour sh, .bashrc pour bash, .cshrc pour csh, .tcshrc pour tcsh...)
 
Edit :
 
Finalement c'est possible qu'on ait raison tous les deux...
 
Je parle du comportement sous FreeBSD, possible que sous linux ce ne soit pas le meme (sous Solaris le comportement est encore different)

ah oui je parle que pour linux, là, pour les autres unices, je sais pas, faut voir le man