Bonsoir à tous et à toutes.
Je viens d’installer DisplayCAL et j’ai ajouté
export PATH=/home/$USER/.local/bin:$PATH
à mon .bashrc.
Ça fonctionne bien dans un terminal mais si je clique sur l’icône « DisplayCAL », j’ai l’erreur : Aucun fichier ou dossier de ce type.
C’est la première distribution avec la quelle ça me fait ça.
Si quelqu’un a une idée pour résoudre mon problème ?
Merci.
salut
tu as utilisé la version buster?
ou les sources ?
mais ça n’est que du python 2?
as tu vérifié que displaycal est dans le /home/$USER/.local/bin?
quelle est le bash exécuté dans ton « icone » ?
tu pourrais rajouter le export dans la commande de l’icone
tu pourrais exécuter la commande de l’icone dans un terminal
Bonjour, dindoun.
J’ai utilisé la méthode décrite ici : https://ignace72.eu/displaycal-en-python-3.html#installation-manuelle
displaycal est bien dans /home/$USER/.local/bin, Quand je tape displaycal dans un terminal, ça fonctionne.
Voilà le code de l’icône :
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=DisplayCAL
Name[de]=DisplayCAL
GenericName=Display Calibration
GenericName[de]=Anzeigegerätekalibrierung
Exec=displaycal
Icon=displaycal
Terminal=false
Categories=Graphics;
Comment[de]=Eine Anzeigegeräte-Kalibrierungs- und Profilierungslösung mit einem Fokus auf Genauigkeit und Vielseitigkeit
Comment=A display calibration and profiling solution with a focus on accuracy and versatility
Si je mets export dans la commande de l’icône, celà fonctionnera-t-il aussi pour les autres exécutables fourni par DisplayCAL qui sont dans ce répertoire ?
Comme c’est dans une machine virtuelle, je ne peux pas tester la calibration et l’installation d’un profil colorimétrique.
.bashrc est utilisé uniquement par bash lorsqu’il est invoqué comme interpréteur interactif.
A ma connaissance les lanceurs du bureau n’utilisent pas bash pour exécuter la commande spécifiée, et même dans le cas contraire ce ne serait pas en tant qu’interpréteur interactif.
Il faudrait plutôt regarder du côté des variables d’environnement dans les paramètres de la session de bureau.
A ma connaissance, le paramètre Exec d’un lanceur du bureau doit être un exécutable, pas une commande du shell.
Si DisplayCAL lui-même ne dépend pas de $PATH pour lancer d’autres programmes situés au même emplacement, alors tu dois pouvoir simplement spécifier le chemin complet de l’exécutable dans Exec.
Comment ces exécutables sont-ils lancés ?
Bonjour, PascalHambourg.
Dans le paramètre Exec, on peut mettre aussi une variable d’environnement, exemple pour gThumb :
env GTK_THEME=Breeze gthumb %U
Quand je regarde les PATH avec printenv, j’ai :
PATH=/home/ignace/.local/bin:/home/ignace/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Dans ~/.profile, j’ai :
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
Les autres programmes sont lancé depuis displaycal.
Non, on peut seulement mettre un exécutable et ses arguments. Ici l’exécutable est env, et c’est lui qui interprète le premier argument comme une variable d’environnement, pas le lanceur. Ceci dit c’est une solution acceptable pour modifier $PATH avant de lancer ton programme.
C’est peut-être trop simple mais en changeant simplement le chemin de la partie Exec avec le path complet dans ton /home/$USER/.local/bin ça ne marcherai pas ?
Du genre un truc comme ça :
[Desktop Entry]
Version=1.0
Type=Application
Name=MyApp
Comment=
Exec=./MyApp
Path=./../../libs/
Terminal=false
etc ...
C’est ce que j’ai déjà suggéré :
Mais ça ne suffit pas si le programme en question invoque lui-même d’autres programmes situés au même emplacement sans spécifier le chemin complet.
C’est le problème classique quand on exécute apt-get ou dpkg avec « su » sans « - », donc sans /sbin ni /usr/sbin dans $PATH ; ces programmes eux-même sont exécutés car ils sont dans /usr/bin mais sont susceptibles d’invoquer d’autres programmes situés dans /sbin ouu /usr/sbin qui ne seront pas trouvés.
Merci pour vos réponses.
La question que je me pose, c’est pourquoi le système ne trouve pas le programme alors que le chemin est contenu dans la variable $PATH de l’utilisateur ?
Du coup il vaut mieux installer dans /usr/local/bin, plutôt que dans le Home du user.
Mais ça rendra du coup exploitable à tous les user du système ayant l’accès à /usr/local/
A vrai dire je travail en règle générale avec des Env (python la grande majorité du temps) ou via des scripts dans /usr/.
Du coup je suis étonné que ça marche ainsi sur d’autre distribution, pour moi les binaire/scripts appelé à l’intérieur de DisplayCAL ne devrait pas être trouvé à moins que le soft soit lancé via un utilisateur ayant le path vers eux.
As-tu comparé avec un autre système comme Arch ou Fedora voir comment ils font ?
pip install displaycal avec sudo installe le programme dans /usr/ donc j’écarte cette installation, j’ai proposé le répertoire /usr/local/ au développeur sans effet.
Sur les autres distributions que j’ai pu tester, soit /home/$USER/.local/bin est déjà dans le PATH, soit l’ajout dans .bashrc suffit et le lanceur fonctionne.
J’ai testé sur openSUSE Leap, openSUSE Tumbleweed, Manjaro Linux, Linux Mint et Xubuntu.
Par contre la version dans les dépôts ne convient pas (trop vielle, j’ai pas l’impression) ?
https://packages.debian.org/search?keywords=displaycal
La version en Python 3 est faite par un autre dev car celui à l’origine de DisplayCAL ne donne plus signe de vie (mais il continu à toucher les donations).
Voilà la liste des paquets disponibles (liste mise à jour aujourd’hui) :
ArchLinux (3.9.6), Manjaro Linux (3.9.6), Mageia Cauldron (3.9.3), Exherbo (3.9.7), Rosa (3.9.4), Parabola (3.9.4), Debian bullseye-backports et Debian Sid (3.9.7).
Je viens de tester la version Debian bullseye-backports et il y a comme un bogue, le numéro de version est : 0.
La réponse est dans la question : parce que le chemin n’est pas dans $PATH. Il n’y a pas de « variable $PATH de l’utilisateur », elle est propre à chaque processus.
Ben, les utilisateurs lancent des processus avec des variables d’environnement propre à chacun des utilisateurs. Par exemple, le $PATH d’un utilisateur n’est pas le même qu’avec l’utilisateur root.
Root est un cas particulier. Mais comprends bien que si tu ajoutes le chemin via .bashrc, il n’est pris en compte que par bash lorsqu’il est lancé comme interpréteur interactif (en gros, dans un terminal).
Au hasard avec l’openSUSE Leap, l’ajout de .local/bin dans .bashrc et un lanceur avec comme commande displaycal, ça fonctionne très bien.
j’ai pas de machine sous la main pour tester mais la différence entre l’Opensuse et Debian côté :
/etc/environment
/etc/profile
/etc/profile.d/*
Bon, il faudrait que je regarde les différences entre mes différentes machines virtuelles.