J'ai une petite question: comment fait un programme (installé dans /usr/bin généralement) pour retrouver des données (dans /usr/share/monprog normalement) ?
Le chemin d'accès est-il écrit directement dans le code source ?
Est-ce un chemin complet ou relatif à l'emplacement du binaire ?
Si c'est le cas, pourquoi avoir choisi de faire ainsi ? Car dans ma situation actuelle, ce serait très pratique si je pouvais copier le binaire ailleurs et ses données. Et cela changerait leur chemin d'accès.
Bien sûr, je peux recompiler en changeant les options du script ./configure. Mais c'est long.
Forum Linux.général Comment fait un programme pour trouver ses données ?
26
mar.
2005
# quel est le besoin ?
Posté par BAud (site web personnel) . Évalué à 3.
de quel programme s'agit-il ?
je suppose que tu auras plus d'explications dans http://www.delafond.org/survielinux/(...)
normalement un programme va lire son fichier de configuration sous /etc, il peut stocker des paramètres liées à l'utilisateur sous $HOME/.programme/ (nom du programme avec un . devant, comme ça c'est un fichier caché)
et stocke ses données soit dans le répertoire courant, soit dans le dernier répertoire utilisé, soit dans un répertoire configuré par l'utilisateur (si le programme a cette fonctionnalité).
c'est une mauvaise idée de mettre les programmes ailleurs, il ne sera pas exécutable par l'utilisateur par défaut car pas dans la variable PATH... (ou alors rajouter le répertoire...) moi j'ai déjà : /usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/jre-1.4.2_06/bin:/usr/NX/bin:/usr/sbin/:/sbin:/home/baud/bin:/usr/NX/bin:/usr/sbin/:/sbin
ah oui, je viens peut-être de comprendre, tu parles des données genre des images ou des sons utilisées en interne par le programme ? bah oui ça doit être compilé dans le programme...
m'enfin il suffit de faire que /usr/share/monprog soit un lien symbolique vers ailleurs et ça suffit : tu peux les mettre où tu veux (faut pouvoir écrire sous /usr/share ;-)
c'est d'ailleurs la manière correcte de faire pour que tout puisse être facilement retrouvé mais pouvoir utiliser une autre partition pour des données internes un peu trop grosses...
Par exemple, pour urpmi, j'ai /var/cache/urpmi -> /mnt/data_linux_hda9/urpmi/ pour éviter de flinguer ma partition principale quand j'installe de nouveaux programmes (je tourne malheureusement avec moins de 100 Mo de libre sur ma partition principale...)
[^] # Re: quel est le besoin ?
Posté par Jonathan Schemoul (site web personnel) . Évalué à 2.
Tout cela pour dire que les programmes ont moultes façons de retrouver leurs données... :) Je t'invite à voir mon code source si tu veux plus d'informations sur les méthodes que j'ai décrit... ( http://appliworks.jondesign.net(...) ) :)
[^] # Re: quel est le besoin ?
Posté par Mildred (site web personnel) . Évalué à 2.
je me demandais si ce chemin d'accès était directement inclus dans le binaire. Et je dois dire que je trouve que c'est une limitation importante car cela veut dire qu'un programme compilé pour aller dans /usr ne peut pas être placé dans /usr/local par exemple.
L'avantage lorsqu'on a un soft qui est installé dans son propre dossier (/opt/GtkRadient/ par exemple) c'est qu'on peut bouger le dossier du soft sans le perturber. L'inconvénient c'est qu'on ne peux pas mettre certaines données en read-only comme on peut le faire sur /usr, il faut faire tous les liens symboliques nécessaire pour les binaires, lib, pages man, ...
Alors, pourquoi ?
[^] # Re: quel est le besoin ?
Posté par BAud (site web personnel) . Évalué à 2.
ils rajouteront une option dans leur fichier de conf' pour aller chercher certaines données ailleurs... comme ça il n'y aura que /etc/fichier_de_conf en dur et tout le reste là où ça te plairait mieux...
Après la distinction /usr et /usr/local est un peu plus fondamentale, c'est la différence entre installation définitive et installation "pour essayer", que ce soit dans le ./configure ne me choque pas trop...
Ce qu'il faut bien voir c'est que si tu commences à tout mettre à des endroits exotiques, ça va commencer à compliquer les choses...
Ce n'est pas pour rien qu'il y a des projets HFS (Hierarchy File System je crois) et LSB (Linux Standard Base)... donc j'en reviens à ma question : quel est ton besoin de faire différement des standards ? ça ne sert qu'à perdre l'administrateur ou l'utilisateur de ton système (modif' du PATH, LD_LIBRARY_PATH, toussa...).
Tu peux notamment mettre tout ce que tu veux en read-only là où tu veux, tant que le filesystem le supporte (pas sur une partition FAT par exemple...).
Après le lien symbolique aura sans doute des droits rwxrwxrwx pour owner/group/other mais ce sont les droits du fichier vers lequel il pointe qui s'appliquent.
# Gnu Stow
Posté par jerome (site web personnel) . Évalué à 2.
Ce que je te propose, c'est de regarder le logiciel GNU/stow, il permet entre autre d'installer un paquet en mode bundle (genre /usr/local/logiciel) et de faire les liens qui vont bien vers /usr/local/bin, etc).
Ce point est vraiment une question, non pas fondementale mais déjà archi-débattue de part et d'autres, google sera donc ton ami.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.