Discussion :

[uriotcea]

Bonjour,

Je suis en C sous linux et j'ai besoin de connaitre le chemin d'installation de l'executable. Alors jusqu'à présent je croyais que argv[0] contenait le nom complet de l'exe avec son chemin, mais en fait ca contient la commande.
Je ne sais pas comment obtenir cette info dans le code, merci de votre aide

[Neckara]

Bonjour,

As-tu essayé de regarder la variable d'environnement pwd ?

[uriotcea]

Oui, mais cela ne fonctionne que si je lance le programme à partir de son répertoire.

[Neckara]

Mais tu as argv[0] qui complétera ce qu'il te manque.

[kwariz]

Oui, mais cela ne fonctionne que si je lance le programme à partir de son répertoire.

Bonjour,

je suppose que l'exécutable est dans le path. Pour déterminer la localisation de l'exécutable tu peux déréférencer le lien /proc/<PID>/exe. En le faisant quick and dirty sans aucuns checks particuliers :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <stdio.h>
#include <unistd.h>
 
int main(int argc, char** argv)
{
  pid_t pid=getpid();
  char path[1024];
  char buffer[1024];
  ssize_t len;
 
  sprintf(path,"/proc/%u/exe", pid);
  len=readlink(path,buffer,1023);
  buffer[len]=0;
 
  printf("%s\n", argv[0]);
  printf("%s\n", path);
  printf("%s\n", buffer);
 
  return 0;
}

Pour rendre ce code utile il est nécessaire de vérifier chaque étape évidemment.

[uriotcea]

Oui probablement qu'en combinant les 2, mais il y plusieurs cas de figure à considérer et ca devient un peu complexe. J'ai donc essayer ca mais ca ne fonctionne pas non plus, ca me répond "echec" et je ne vois pas pourquoi

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
std::string get_selfpath() {
    char buff[1024];
    ssize_t len = ::readlink("/proc/self/mon_exe_name", buff, sizeof(buff)-1);
    if (len != -1) {
      buff[len] = '\0';
      return std::string(buff);
    } else {
      return("Echec");
    }
}

[kwariz]

Oui probablement qu'en combinant les 2, mais il y plusieurs cas de figure à considérer et ca devient un peu complexe. J'ai donc essayer ca mais ca ne fonctionne pas non plus, ca me répond "echec" et je ne vois pas pourquoi

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
std::string get_selfpath() {
    char buff[1024];
    ssize_t len = ::readlink("/proc/self/mon_exe_name", buff, sizeof(buff)-1);
    if (len != -1) {
      buff[len] = '\0';
      return std::string(buff);
    } else {
      return("Echec");
    }
}

Bon c'est du C++ mais essaye simplement avec "/proc/self/exe" ... tu comprendras mieux si tu fais un ls -l /proc/self

[uriotcea]

Ok merci, j'ai compris mon erreur d'interpretation, ca fonctionne maintenant, merci beaucoup. Une derniére remarque, cela fonctionnera-t-il aussi sous MacOS?

[kwariz]

Je ne sais pas, mais après avoir rapidement jeté un coup d'œil avec google il me semble que non ...

[gangsoleil]

Bonjour,

Il n'y a rien de standard pour faire ce que tu veux : argv[0] DOIT contenir le nom de l'executable, mais rien ne te garantit qu'il contienne le chemin, ni le contraire d'ailleurs.

Sous linux, tu as effectivement /proc/<pid>/..., mais cela ne fonctionne pas sur tous les Unix - et je n'ai pas de mac sous la main pour tester.

Mais on peut aussi se demander pourquoi tu as besoin du chemin absolu ?

[Sve@r]

Bonjour,

Il n'y a rien de standard pour faire ce que tu veux : argv[0] DOIT contenir le nom de l'executable, mais rien ne te garantit qu'il contienne le chemin, ni le contraire d'ailleurs.

Salut
En fait, argv[0] contient le nom exact de l'exécutable tel qu'il a été appelé.
Donc si on appelle "./././truc" ; argv[0] contient la chaine telle qu'elle (sans optimisation aucune)

Donc pour connaitre le chemin de l'exécutable de façon vraiment portable, 3 choix possibles
1) si argv[0] commence par "/", pas de souci, t'as le nom direct
2) s'il ne commence pas par "/" mais qu'il y a un "/" dans son nom, alors récupérer le chemin complet jusqu'au nom final (ce chemin constitue en fait le chemin relatif allant jusqu'à l'exécutable) et le concaténer avec pwd. Même si le chemin a été appelé de façon biscornue (en jouant avec les . et les ..) on aura quand-même un chemin disponible
3) s'il n'y a pas de / dans le nom, alors extraire les dossiers du PATH et regarder quel dossier contient ledit exécutable (exactement comme fait "whereis" ou "which")

Mais on peut aussi se demander pourquoi tu as besoin du chemin absolu ?

Très bonne question. Dans 99,999% des cas, le chemin relatif suffit...

[kwariz]

Salut
En fait, argv[0] contient le nom exact de l'exécutable tel qu'il a été appelé.
Donc si on appelle "./././truc" ; argv[0] contient la chaine telle qu'elle (sans optimisation aucune)

Donc pour connaitre le chemin de l'exécutable de façon vraiment portable, 3 choix possibles
1) si argv[0] commence par "/", pas de souci, t'as le nom direct
2) s'il ne commence pas par "/" mais qu'il y a un "/" dans son nom, alors récupérer le chemin complet jusqu'au nom final (ce chemin constitue en fait le chemin relatif allant jusqu'à l'exécutable) et le concaténer avec pwd. Même si le chemin a été appelé de façon biscornue (en jouant avec les . et les ..) on aura quand-même un chemin disponible
3) s'il n'y a pas de / dans le nom, alors extraire les dossiers du PATH et regarder quel dossier contient ledit exécutable (exactement comme fait "whereis" ou "which")


Très bonne question. Dans 99,999% des cas, le chemin relatif suffit...

Bonsoir,

4) il y a les cas "extrêmes" où la commande elle-même est un lien qu'il faut d'abord déréférencer avant de cherche l'exécutable dans le PATH ...

[uriotcea]

Merci de vos réponse, mais la méthode basée sur readlink me parait simple et fiable. Si j'ai besoin du chemin exact de l'exe, c'est parce que des library son placée au même path que l'exe et que dans le code de l'exe je dois positionner des variables d'env désignant le chemin de ces libraires.

[Sve@r]

Bonsoir,

4) il y a les cas "extrêmes" où la commande elle-même est un lien qu'il faut d'abord déréférencer avant de cherche l'exécutable dans le PATH ...

5) autre cas à la con: quand un chemin du PATH est lui-même un nom relatif (style "." ou "..")...

Si j'ai besoin du chemin exact de l'exe, c'est parce que des library son placée au même path que l'exe et que dans le code de l'exe je dois positionner des variables d'env désignant le chemin de ces libraires.

Donc le chemin relatif suffit. Car le chemin relatif est aussi celui des librairies et l'exe peut l'utiliser pour y accéder même en relatif...

[uriotcea]

Oui je suppose que le chemin relatif devrait fonctionner aussi, mais honnêtement, j'ai beaucoup de mal à développer autrement qu'avec les chemins absolus.

[Sve@r]

Oui je suppose que le chemin relatif devrait fonctionner aussi, mais honnêtement, j'ai beaucoup de mal à développer autrement qu'avec les chemins absolus.

Les deux méthodes ont des avantages et des inconvénients. Travailler en chemin relatif t'oblige à toujours savoir où tu te trouves et où tu te trouveras au bout du chemin que tu nommes. Mais dans un gros projet, tu peux prendre la racine du projet et la déplacer ensuite très facilement ; ou même créer une racine v0.1 contenant tout le projet puis le dupliquer dans une v0.2 sans avoir à modifier quoi que ce soit dans le code ni dans les liens liant parfois les dossiers les uns aux autres.

Travailler en absolu apporte un certain confort et une certaine sérénité dans la conception mais t'oblige ensuite, en cas de changement, à répertorier les changements partout où les chemins sont nommés. Toutefois on peut essayer d'atténuer ce souci comme par exemple répertorier les chemins dans des variables et des fichiers ini ce qui facilite les mises à jour. Mais si les chemins relatifs existent, c'est qu'ils ont leur utilité.

PS: quand on crée un raccourci sous Windows, le raccourci contient toujours l'emplacement du fichier cible nommé en absolu (C:\...). Et parfois ça me gonfle...

[uriotcea]

Oui je suis d'accord avec toi, mais venant du monde Windows, comme tu le dis justement, je me sens plus serein avec les chemin absolue et effectivement je suis obligé d'initialiser tous les chemins avec une fonction définie pour ca. Et comme je dois porter mes applis sous 3 OS (Windows, Linux et macos), ca me simplifie considérablement la vie d'être toujours en absolue et donc quelque part systeme indépendant de ce coté là.

[kwariz]

Oui je suis d'accord avec toi, mais venant du monde Windows, comme tu le dis justement, je me sens plus serein avec les chemin absolue et effectivement je suis obligé d'initialiser tous les chemins avec une fonction définie pour ca. Et comme je dois porter mes applis sous 3 OS (Windows, Linux et macos), ca me simplifie considérablement la vie d'être toujours en absolue et donc quelque part systeme indépendant de ce coté là.

Bonjour,

si tu développes pour 3 plateformes ça se compliue toujours un peu dès que tu dois gérer des chemins à moins d'utiliser des bibliothèques qui sont elles-mêmes multiplateformes. Donc ça va non seulement dépendre de tes outils de dev mais aussi de ta procédure d'install.
Tu as déjà essayé autoconf+glib+gtk ?Avec ça tu développes relativement facilement.
Ensuite pour l'installation cela va dépendre de celui qui installe : un user linux ne verra pas de problèmes particuliers avec un «configure & make & sudo make install», un utilisateur ubuntu préfèrera certainement double cliquer sur un paquet managé en s'en foutant où sera installé le programme et l'utilisateur windows s'attendra à pouvoir choisir le répertoire d'installation : à ma connaissance il n'y a pas de solutions miracles et multiplateformes, il n'y a que des outils adaptés à chaque plateforme (msi,deb,txz,rpm, ...)

[uriotcea]

Oui, tout a fait d'accord, c'est pourquoi quel que soit la plateforme, je m'arrange toujours pour qu'il n'est pas d'installation a réaliser (tout est toujours développer en static). De plus habituellement j'utilise Qt, sauf que là, je suis sur un cas particulier sans Qt et sans C++, ce qui me pose certain problème, n'ayant plus l'habitude de ces problèmes de portabilité.

[gangsoleil]

Salut
En fait, argv[0] contient le nom exact de l'exécutable tel qu'il a été appelé.
Donc si on appelle "./././truc" ; argv[0] contient la chaine telle qu'elle (sans optimisation aucune)

Pas tout a fait. La norme C99 precise :

the string pointed to by argv[0]
represents the program name; argv[0][0] shall be the null character if the
program name is not available from the host environment.

Le reste est dependant de l'OS -- meme si on voit souvent le nom de l'executable tel qu'appele.