Forum Linux.général Où est mon terminal ?

Posté par chimrod (site web personnel) le 09 avril 2021 à 12:01. Licence CC By‑SA.

Étiquettes : aucune

avr.

2021

Bonjour à tous,

j'ai récemment décidé de changer de terminal sur mon bureau (c'est ma vie, on s'en fout un peu). Sauf que c'est pas si simple : j'utilise parfois le terminal pour lancer un shell et des commandes, et je l'utilise parfois pour lancer une application directement. Par exemple, quand je suis dans mon gestionnaire de fichier (pcmanfm-qt), dès que je veux ouvrir un fichier texte (associé avec Neovim), mon bureau ouvre le terminal rxvt, alors que celui-ci n'est pas configuré comme étant mon terminal par défaut…

Voilà les étapes qui sont réalisées au moment où je clique sur mon fichier à ouvrir :

Identifier l'application associée au type

Cela se fait en allant chercher le fichier /usr/share/applications/mimeinfo.cache. À l'intérieur on y trouve une référence à nvim.desktop

Rechercher quelle commande lancer pour `nvim`

Il est présent dans le même répertoire : /usr/share/applications/nvim.desktop et je trouve à l'intérieur les deux lignes suivantes :

Exec=nvim %F
Terminal=true

Lancer la commande dans un terminal

Je suppose donc que désormais, il ne reste plus qu'à lancer la commande un terminal. Mais lequel ? Je ne trouve aucune information qui me permette de savoir lequel est sélectionné.

Quand je lance ce process dans un strace j'obtiens cette liste qui me laisse un peu perplexe :

stat("/usr/bin/nvim", {st_mode=S_IFREG|0755, st_size=3882736, ...}) = 0
access("/usr/bin/nvim", X_OK)           = 0
getuid()                                = 1000
stat("/usr/bin/nvim", {st_mode=S_IFREG|0755, st_size=3882736, ...}) = 0
access("/usr/local/bin/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/bin/gnome-terminal", X_OK)     = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/games/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/games/gnome-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/bin/mate-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/mate-terminal", X_OK)  = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/bin/mate-terminal", X_OK)      = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/games/mate-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/games/mate-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/bin/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/bin/xfce4-terminal", X_OK)     = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/games/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/games/xfce4-terminal", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/bin/nxterm", X_OK)   = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/nxterm", X_OK)         = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/bin/nxterm", X_OK)             = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/games/nxterm", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/games/nxterm", X_OK)       = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/bin/color-xterm", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/color-xterm", X_OK)    = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/bin/color-xterm", X_OK)        = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/games/color-xterm", X_OK) = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/games/color-xterm", X_OK)  = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/local/bin/rxvt", X_OK)     = -1 ENOENT (Aucun fichier ou dossier de ce type)
access("/usr/bin/rxvt", X_OK)           = 0
getuid()                                = 1000
stat("/usr/bin/rxvt", {st_mode=S_IFREG|S_ISGID|0755, st_size=1411072, ...}) = 0

On dirait que l'ensemble du path est parcouru avec une liste prédéfinie de commandes. D'où sortent-elles ? Pourquoi cet ordre là ? C'est là où j'ai besoin de vos lumières pour comprendre ce qui se passe dans ma machine…

Je vous remercie d'avance !

# xdg-open?

Posté par saltimbanque (site web personnel) le 09 avril 2021 à 13:06. Évalué à 2.

Si tu utilises la commande xdg-open (qui appelle le programme par défaut) je m'attend à ce que tu obtienne le même résultat. Et bien sûr cela peut être changé. Si jamais cela ne te permet pas de résoudre, il faudra connaître la distrib que tu utilises.
- [^] # Re: xdg-open?
  
  Posté par chimrod (site web personnel) le 09 avril 2021 à 13:23. Évalué à 2. Dernière modification le 09 avril 2021 à 13:24.
  Bonjour,
  
  Merci pour ton retour, je suis sous debian.
  
  Le comportement avec xdg-open diffère :
  - Quand je lance la commande depuis un terminal, ça me lance l'éditeur dans le terminal courant (quel que soit ledit terminal)
  - Quand je lance la commande depuis un prompt au niveau du gestionnaire de fenêtre : ça m'ouvre l'éditeur dans le terminal par défaut
  Par contre je ne sais pas ce que lance le gestionnaire de fichier au moment où je clique sur l'icone de mon fichier…
  
  J'ai essayé de lire le code de xdg-open pour voir comment était traité le cas du Terminal=true mais n'ai pas réussi à trouver où cela était géré.
  - [^] # Re: xdg-open?
    
    Posté par saltimbanque (site web personnel) le 09 avril 2021 à 15:33. Évalué à 3.
    
    j'ai l'impression que d'autres ont le même problème que toi, et que xdg-open serait imparfait. Je ne crois pas que tu aies précisé de bureau, seulement un gestionnaire de fenêtre?
    
    le wiki de Arch semble indiquer des alternatives,
    https://wiki.archlinux.org/index.php/default_applications
    - [^] # Re: xdg-open?
      
      Posté par chimrod (site web personnel) le 09 avril 2021 à 17:54. Évalué à 2.
      
      J'utilise i3 comme WM, avec lxqt comme bureau (réduit presque au minimum). Mais plus je suis en train de chercher, plus j'ai l'impression que le problème vient du navigateur de fichier — où d'un composant dans la chaîne qui aurait stocké une liste de terminaux qques part, sauf que j'arrive pas à mettre la main dessus, et ça m'énerve ! :)
  - [^] # Re: xdg-open?
    
    Posté par NeoX le 09 avril 2021 à 16:04. Évalué à 2.
    
    Quand je lance la commande depuis un prompt au niveau du gestionnaire de fenêtre : ça m'ouvre l'éditeur dans le terminal par défaut
    
    ben suffit de changer, dans les options du gestionnaire de fenêtre, le terminal qui sera utilisé par défaut
    - [^] # Re: xdg-open?
      
      Posté par chimrod (site web personnel) le 09 avril 2021 à 18:59. Évalué à 2.
      
      Malheureusement, il n'est pas pris en compte quand je fais ça depuis mon navigateur de fichier, et c'est bien là mon malheur.
      
      Je vais tester avec autre chose que pcmanfm-qt. Le problème vient peut-être de là…
      - [^] # Re: xdg-open?
        
        Posté par chimrod (site web personnel) le 11 avril 2021 à 18:16. Évalué à 2.
        
        Bon, je pense avoir trouvé la source de mon problème : la Glib utilise une liste de terminaux dans une liste pré-définie en dur dans le code :
        
        https://github.com/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L2581
        
        Par contre, je n'ai aucune idée de savoir comment contourner ce problème, ni même a qui le remonter !
        
        [^] # Re: xdg-open?
        
        Posté par chimrod (site web personnel) le 11 avril 2021 à 18:40. Évalué à 2.
        
        Bon, j'ai l'impression de voyager dans le temps…
        
        J'ai trouvé un ticket qui correspond à mon problème mais qui aurait été clos en 2018 ! Il faut maintenant comprendre pourquoi j'ai encore le problème sur mon PC !
        
        [^] # Re: xdg-open?
        
        Posté par NeoX le 12 avril 2021 à 08:24. Évalué à 2.
        
        mon problème mais qui aurait été clos en 2018 ! […] comprendre pourquoi j'ai encore le problème sur mon PC !
        
        parce que tu as une veille distribution qui n'a pas été mise à jour depuis ?
        
        [^] # Re: xdg-open?
        
        Posté par chimrod (site web personnel) le 12 avril 2021 à 09:12. Évalué à 2.
        
        Bien essayé mais non :) Je suis à mi-chemin entre la version stable et la version testing (prochaine version stable) pour certains paquets.
        
        Quand je regarde le patch et les changements apportés, j'ai l'impression qu'il ne gère pas toutes les branches et qu'il reste encore des appels au code de la GLib. Peut-être que je tombe dans l'un de ces cas là. (mais mes connaissances ne me permettent pas d'aller plus loin). Afin d'être sûr, j'ai installé hier le paquet "xfce4-terminal", qui se trouve en amont dans la liste des terminaux testés par la GLib, et c'est bien celui là qui s'est lancé quand j'ai voulu éditer mon fichier (je trouve ça un peu archaïque de coder en dur les applications dans une librairies, mais bon, c'est pas le sujet…)
        
        Au moins j'ai l'explication désormais, même si le fonctionnement n'est pas normal, le fait de savoir d'où vient le problème est déjà quelque chose de rassurant (les bugs ça existe et c'est normal, ça m'inquiète davantage de ne pas comprendre pourquoi le système ne fonctionne pas comme attendu).
        
        J'ai ouvert un rapport d'incident chez Debian, à suivre !
        
        [^] # Re: xdg-open?
        
        Posté par NeoX le 12 avril 2021 à 10:14. Évalué à 3.
        
        est-ce que la GLIB ne prendrait pas dans la liste en dur si et seulement si une variable n'est pas définie ?
        
        reste à determiner quelle variable ?
        
        bon apparemment c'est un probleme vieux de 9ans,
        avec personne qui veut coder le changement,
        puis depuis un an ça évolue et des nouveautés vont arriver
        
        https://gitlab.gnome.org/GNOME/glib/-/issues/338
        
        [^] # Re: xdg-open?
        
        Posté par chimrod (site web personnel) le 12 avril 2021 à 10:49. Évalué à 2.
        
        Super merci du lien !
        
        J'aime beaucoup ce genre de cheminement, qui part d'un problème complètement anodin, et fini vers une chaine d'erreur touchant plusieurs librairies…
        
        Par contre, il faut savoir naviguer entre les différents projets pour identifier les anomalies, ce qui n'est pas simple du tout.
# Du nouveau semble t'il

Posté par saltimbanque (site web personnel) le 05 mai 2021 à 17:23. Évalué à 2.
Peux être es tu un ami de David Faure.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45

Son mail
```
I just created
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45
with the proposal for an intent-apps spec, modeled after the mime-apps spec
(but without the concept of adding/removing associations).

For context:
- The desktop entry spec mentions Implement= already for some
  time, but AFAIK this isn't used anywhere yet?
- What's missing is a way to let the user (or the sysadmin or the distro)
  decide which alternative to prefer (possibly depending on the desktop
  environment). mimeapps does this nicely for mimetypes, so intentapps just
  reuses that solution, but outside the world of mimetypes
- This came up in https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
  where we're discussing "Have a standard way for users to specify which
  terminal should open .desktop applications with Terminal=true".
  The solution involves implementing a DBus interface (dubbed
  org.freedesktop.Terminal1). This is similar to the existing
  org.freedesktop.FileManager1 DBus interface. All applications implementing
  org.freedesktop.Terminal1 will specify
  Implements=org.freedesktop.Terminal1 in their desktop file, and intent-
  apps.lst files can then be used to pick the preferred one.
I am willing to implement this on the KDE side, I'm especially interested in
feedback from whoever feels like implementing this in glib and other
implementations.

--
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
```