Discussion :

[ctac_]

Bonjour,
Je suis d'accord pour les fichiers .desktop.
Par exemple pour xcalc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Exec='/home/alain/bin/ctac authentication agent' '/usr/bin/xcalc'

Pourquoi persistes-tu à me dire que la bonne commande est celle que tu donnes puiqu'elle me retourne une erreur comme spécifié ici:
https://www.developpez.net/forums/d2.../#post11417715

Il n'y a aucun intérêt de lancer xcalc en root mis a part le fait de m'indiquer que ta commande présente un défaut qui doit être corrigé.
Ce problème pourrait certainement se produire pour un autre programme.

Que se passe t'il ici ?
Je pense que xcalc reçoit en paramètre une chaîne vide dont il ne sait que faire puisque ça ne correspond a aucune de ses options et retourne donc une erreur.

La commande qui fonctionne est celle ci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
        -e 'pkttyagent &
           nohup pkexec '"'$1'"' '"${2:+'$2'}"' > /tmp/leret$org 2>/tmp/leret$org 0<&-' &

Je pense que cette commande qui n'a pas de sens (ou en tout cas aucun intérêt) permet de transformer $2 (une chaîne vide) en rien, ce qui fait que xcalc ne reçoit aucun paramètre et s'exécute correctement.

Après, concernant les problèmes particuliers qu'il peut y avoir avec thunar ou mousepad, c'est autre chose.

Effectivement, je m'aperçoit que chaque fois que je lance mousepad ou thunar en root et que ça ne fonctionne pas, j'obtiens une ligne comme suit dans /var/log/user.log

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mar 13 17:20:32 debian-linux [3502]: Name org.xfce.Xfconf lost on the message dbus, exiting.

Donc, c'est bien comme sur OpenBSD, il y a un problème avec xfconf.

Mais soit dit en passant, ces applis ne sont pas faites pour être lancées en tant que root, et il n'y a pas de bonne raison de le faire.

Ici, je suis surpris.
Pour mousepad:
Ne t'arrive t'il jamais de modifier un fichier de configuration système ?
Pour thunar:
Comment fait tu pour accéder au répertoire /var/log/lightdm par exemple ?

En tous cas, merci à tous pour la suppression de l'affichage parasite de nohup et la simplification de mon code.
Il me reste maintenant a retrouver xfconf dans le message bus!
Cordialement.

[balkany]

Pourquoi persistes-tu à me dire que la bonne commande est celle que tu donnes puiqu'elle me retourne une erreur comme spécifié ici:
https://www.developpez.net/forums/d2.../#post11417715

Parce que c'est la bonne commande
Mais tu as raison, il ne faut pas toujours entourer $2 de guillemets, sinon pkexec passe une chaine vide à xcalc qui ne sait pas quoi en faire : je n'ai pas pu bien tester ça, car chez moi, le lancement de xcalc par pkexec refuse tout simplement de se faire.
En fait, je pensais à tort que pkexec « faisait le tri », et ne passait pas une chaine vide à la commande qu'il lance.
Donc, en reprenant ton idée (qui a bien du sens et un intérêt) du développement de paramètre seulement s'il est non vide, on peut faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
-e "pkttyagent &
          nohup pkexec '$1' ${2+'$2'} >/tmp/leret$org 2>/tmp/leret$org 0<&-" &

C'est quand même mieux qu'avec tous ces guillemets simples / doubles dans tous les sens, non ? (et comme ça, tu n'as pas besoin d'exporter org)

Ici, je suis surpris.
Pour mousepad:
Ne t'arrive t'il jamais de modifier un fichier de configuration système ?
Pour thunar:
Comment fait tu pour accéder au répertoire /var/log/lightdm par exemple ?

Si je modifie un fichier système, je le fais avec vim, et si jamais je voulais le faire avec mousepad, je ferais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SUDO_EDITOR=mousepad sudoedit fichier

Ainsi, mousepad est lancé avec les droits de simple utilisateur, toutes les modifs, jusqu'à l'enregistrement, sont faites sur un fichier temporaire, et c'est seulement à la fermeture de mousepad que les droits d'admin sont utilisés, pour copier le fichier temporaire sur le fichier cible.
Quant aux répertoires système qui ne sont pas lisibles ou traversables en tant que simple utilisateur, j'y accède en ligne de commande, pas via un gestionnaire de fichiers graphique (de même que pour tous les répertoires système en fait).

[disedorgue]

Perso, je rajouterai un sleep 1 juste après le pkttyagent &, histoire de lui laisser le temps de démarrer avant de lancer une commande qui l'utilise...

[ctac_]

Bonjour,

-e "pkttyagent &
nohup pkexec '$1' ${2+'$2'} >/tmp/leret$org 2>/tmp/leret$org 0<&-" &

effectivement, ça fonctionne ainsi et c'est bien plus simple. merci.
Le nez dans le guidon...

Perso, je rajouterai un sleep 1 juste après le pkttyagent &, histoire de lui laisser le temps de démarrer avant de lancer une commande qui l'utilise...

C'est une bonne idée qui malheureusement ne fonctionne pas ni sur debian, ni sur OpenBSD.
Quoi que je lance, j'obtiens une messagebox sans texte avec mon bouton Dommage.
Cordialement.
[Edit]
En prolongeant le sleep qui vient juste après le lancement de xterm, ça va tout de suite mieux.
Merci bien.

[ctac_]

je n'ai pas pu bien tester ça, car chez moi, le lancement de xcalc par pkexec refuse tout simplement de se faire.

C'est expliqué pourquoi ici https://forum.openbsd.fr.eu.org/show...20104#pid20104 dans le message sur openbsd.fr.eu.org
Cordialement.

[balkany]

Oui, effectivement : j'étais dans le cas « Can't open display », et en rajoutant les lignes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/xcalc</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>

au fichier /usr/share/polkit-1/actions/org.freedesktop.policykit.policy, xcalc se lance bien via pkexec.
Cela dit, je vais m'empresser de remettre en place la politique par défaut.