Obtention du path actuel dans la command .desktop EXEC

Im essayant de faire un file .desktop exécuter un .sh qui est stocké dans le même directory que le .desktop. Tout le directory doit être portable et déplacé d'une machine à l'autre.

mon script d'exécution est run.sh

J'ai essayé:

 [Desktop Entry] Type=Application Terminal=true Name=RunMe #Exec=sh -c "`dirname %k`/run.sh" #Exec=bash -c "export PATH=$PATH:`dirname %k`; bash run.sh;" #Exec=bash -c "export PATH=$PATH:`dirname %k`; sh run.sh;" Exec=bash -c "export PATH=$PATH:`dirname %k`; run.sh;" 

Mais rien ne se passe quand je double-clique sur le file .desktop. Si je double-clique sur "run.sh" et que je choisis "run", le script fonctionne correctement. Si sh run.sh le script à partir de la command line avec ' sh run.sh ' cela fonctionne très bien.

Toutes les idées, même juste comment je pourrais déboguer quel path il essayait réellement de courir?

Selon les spécifications d'input de bureau :

Les codes de champ ne doivent pas être utilisés dans un argument cité

Par conséquent, votre %k est donné littéralement à la command bash . Changer la ligne Exec à la suivante évite de le faire:

 Exec=bash -c '"$(dirname "$1")"/run.sh' dummy %k 

Ce qui précède fonctionne localement, et fonctionne également s'il y a un espace dans le path. dummy est donné au script bash tant que $0 (ce qu'il pense être le nom du script), et l'extension de %k est disponible en tant que $1 . Les couches nestedes de cotation sont nécessaires pour se conformer à la spécification et être sécurisées dans l'espace.

Notez que %k ne s'étend pas nécessairement à un path de file local – il peut s'agir d'un URI Vfolder, ou vide, et un script vraiment portable devrait également prendre en count ces cas. %k n'est pas universellement pris en charge lui-même, vous aurez donc besoin de certaines contraintes sur les systèmes que vous prévoyez de l'utiliser de toute façon.


En ce qui concerne le debugging, vous pouvez utiliser la redirection de shell ordinaire sous KDE:

 Exec=bash -c ... > /tmp/desktop.log 

Ce n'est pas un comportement standardisé, et cela ne fonctionne pas sous GNOME et probablement d'autres. Vous pouvez également donner un path absolu à un script conçu pour consigner ses arguments et ses actions de la manière dont vous en avez besoin.

Si le script se trouve dans le même directory que le file .desktop , utilisez uniquement des paths relatifs. Il n'y a aucune raison de jouer avec bash -c ou de modifier votre $PATH et bien less de dirname :

 [Desktop Entry] Type=Application Terminal=true Name=RunMe Exec=./run.sh 

Tant que votre run.sh trouve dans le même directory que le file .desktop et qu'il possède une ligne shebang correcte:

 #!/usr/bin/env bash 

Ça devrait marcher n'importe où. L'utilisation de #!/usr/bin/env bash au lieu de #!/bin/bash garantit que le bash de l'user $PATH sera utilisé et rendra votre script entièrement portable.


NOTE: @MichaelHomer a souligné dans les commentaires que les paths relatifs ne fonctionnent pas sur tous les environnements de bureau. J'ai essayé ceci sur Cinnamon et cela a fonctionné comme prévu donc, vraisemblablement, cela devrait aussi fonctionner sur d'autres environnements basés sur Gnome. Les spécifications de freedesktop.org semblent suggérer qu'un path complet devrait être utilisé:

La key Exec doit contenir une command line. Une command line consiste en un programme exécutable éventuellement suivi d'un ou plusieurs arguments. Le programme exécutable peut être spécifié avec son path complet ou avec le nom de l'exécutable uniquement . Si aucun path d'access complet n'est fourni, l'exécutable est recherché dans la variable d'environnement $ PATH utilisée par l'environnement de bureau. Le nom ou le path du programme exécutable peut ne pas contenir le signe égal ("="). Les arguments sont séparés par un espace.