Discussion :

[LeBigornot]

Bonjour,
Je lance mon application par ligne de commande et j'aimerais connaitre le chemin de l'executable pour sauvegarder mes fichiers.
Car j'utilise le répertoire courant mais il n'est pas forcement le même que celui de l'exécutable.
Existe t'il une fonction?

merci

[Médinoc]

Plusieurs moyens:

En C standard, tu peux avoir la ligne de commande avec les paramètres de main() : argv[0] correspond à la commande du programme.

Malheureusement, les fonctions d'exécution de programme permettent de choisir les paramètres, le programme risque donc d'avoir été lancé avec un argv[0] erroné ou incomplet...

Sous Windows, tu as la fonction GetModuleFileName() qui marche très bien (passe-lui NULL comme paramètre HMODULE et elle te renverra le chemin de l'exécutable)

Sous Unixoïde, aucune idée: Il peut y avoir une fonction spécifique, mais dans ce cas, j'ignore laquelle...

[Emmanuel Delahaye]

Plusieurs moyens:

En C standard, tu peux avoir la ligne de commande avec les paramètres de main() : argv[0] correspond à la commande du programme.

La norme dit que argv[0] peut contenir soit

• "" (une chaine vide)
• le nom du programme
• le nom du programme avec le chemin complet

Ce n'est donc pas une méthode fiable.

[Médinoc]

Euh... Je ne le trouve pratiquement nulle part.
("no manual entry for getpwd" sur deux serveurs unix (HP_UX et FreeBSD), rien sur MSDN, et google qui me conseille getcwd())

Il y a bien getcwd(), mais...

Car j'utilise le répertoire courant mais il n'est pas forcement le même que celui de l'exécutable.

[Emmanuel Delahaye]

Euh... Je ne le trouve pratiquement nulle part.
("no manual entry for getpwd" sur deux serveurs unix (HP_UX et FreeBSD), rien sur MSDN, et google qui me conseille getcwd())

Il y a bien getcwd(), mais...

Car j'utilise le répertoire courant mais il n'est pas forcement le même que celui de l'exécutable.

Oups c'est ce que je voulais dire (GET Current Working Directory), mais effectivement, ça ne répond pas à la question.

J'efface.

[Franck.H]

...j'aimerais connaitre le chemin de l'executable pour sauvegarder mes fichiers.
Car j'utilise le répertoire courant mais il n'est pas forcement le même que celui de l'exécutable.

Pour acceder au repertoire courant, toujours POSIX par contre, une des trois pourraient faire l'affaire

getcwd
getwd (BSD)
get_current_working_dir_name (extension GNU)

Si ca peut aider

[Médinoc]

ben non, ça peut pas aider: On cherche le répertoire du programme, pas le répertoire courant...

[David.Schris]

Sous linux, c'est moins évident :

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
21
22
23
Si argv[0] est vide alors
    afficher "je ne sais pas faire"
    Quitter
Sinon si argv[0] commence par '/'
    cheminAbsolu <- argv[0]
Sinon si argv[0] contient un '/'
    cheminAbsolu <- getcwd() (+'/') + argv[0]
Sinon
    nomExe <- argv[0]
    trouve <- FAUX
    Pour chaque nom de répertoire présent dans la variable PATH
        cheminAbsolu <- repertoireDePATH (+'/') + nomExe
        Si cheminAbsolu correspond à un fichier exécutable
            trouve <- VRAI
            Sortir de la boucle
        Fin si
    Fin pour
    Si pas trouve
        afficher "pas trouve"
        Quitter
    Fin si
Fin si
vraiCheminAbsolu <- cheminCanonique(cheminAbsolu)

Pour obtenir le chemin canonique, la fonction realpath() fait déjà le travail.
Si vous avez plus simple, je prends.

[LeBigornot]

Merci de vos réponses mais je n'y trouve malheureusement pas moj bonheur
Donc je vais vous expliquer plus en détail mon problème peut être que vous m'y apporterer une autre solution:
C'est un programme C sous Linux devant s'executer si possible sur toutes les plateformes Unix.
Pour le lancer automatiquement j'utilise la commande

Code :

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

1
2
 
su - toto-c "/apps/program/monprog/monprog -b"

Dans mon prog j'écris des fichiers et j'aimerais les écrire dans le repertoire "monrpog" et pas à la racine.

Merci

[Franck.H]

ben non, ça peut pas aider: On cherche le répertoire du programme, pas le répertoire courant...

Bin à ce que j'ai pu lire, getcwd récupère le répertoire courant du processus en cours d'execution, ce qui devrait faire l'affaire dans ce cas précis ... je suppose ! Sinon je ne vois pas ce qu'il cherche !

[Franck.H]

Pour le lancer automatiquement j'utilise la commande

Code :

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

1
2
 
su - toto-c "/apps/program/monprog/monprog -b"

Dans mon prog j'écris des fichiers et j'aimerais les écrire dans le repertoire "monrpog" et pas à la racine.

Hé, dans ce cas bien précis, utiliser un chemin relatif suffirait amplement, je ne vois pas en quoi vous vous compliquez la vie, tu donnes juste le nom du fichier quand tu veut en créer un puis il se met automatiquement dans le répertoire .../monprog/ !

[David.Schris]

Merci de vos réponses mais je n'y trouve malheureusement pas moj bonheur
Donc je vais vous expliquer plus en détail mon problème peut être que vous m'y apporterer une autre solution

Pour ma part, je pense avoir bien compris le problème. Inutile de l'exposer de nouveau.
Qu'est-ce qui ne vous plait pas dans ma solution ? Est-ce qu'elle ne fonctionne pas ? L'avez-vous essayée ?
Si vous trouvez une fonction toute faite (et portable) qui permet de se passer de ma solution : n'hésitez pas à m'en faire part, cela me permettra de simplifier certains de mes programmes.

[DaZumba]

Si vous trouvez une fonction toute faite (et portable) qui permet de se passer de ma solution : n'hésitez pas à m'en faire part, cela me permettra de simplifier certains de mes programmes.

Le probleme de LeBigornot n'est pas simple a resoudre de facon portable. De toute facon, devoir resoudre un tel probleme est symptomatique d'une conception mal pensee.
J'imagine que s'il a besoin de connaitre le chemin complet vers son executable, c'est qu'il souhaite trouver un fichier de configuration, d'initialisation, ou de donnees. Il est beaucoup plus robuste d'utiliser une variable d'environnement dans ces conditions (en environnement multi-utilisateur, par exemple, le fichier de configuration va varier d'un utilisateur a l'autre, et le repertoire contenant l'executable n'est certainement pas disponible en ecriture a tous les utilisateurs).

[LeBigornot]

Le probleme de LeBigornot n'est pas simple a resoudre de facon portable. De toute facon, devoir resoudre un tel probleme est symptomatique d'une conception mal pensee.
J'imagine que s'il a besoin de connaitre le chemin complet vers son executable, c'est qu'il souhaite trouver un fichier de configuration, d'initialisation, ou de donnees. Il est beaucoup plus robuste d'utiliser une variable d'environnement dans ces conditions (en environnement multi-utilisateur, par exemple, le fichier de configuration va varier d'un utilisateur a l'autre, et le repertoire contenant l'executable n'est certainement pas disponible en ecriture a tous les utilisateurs).

j'aime bien ce concept de conception mal pensée.
En gros tu penses qu'aller lire une variable d'environement dans laquel l'utilisateur aura rentré le chemin d'acces (ou a l'installation) est suffisant ? C'est vrai que cela simplifierait problème...

Même si mon problème n'est pas clair je ne suis pas issu du monde Unix et je ne connais pas la façon "standard" de faire cela.

Quitte a lire une variable d'environement pourquoi pas stocker le répertoire d'install dans mon fichier de configuration (passé en paramètre a l'application) alors ?

Pour ma part, je pense avoir bien compris le problème. Inutile de l'exposer de nouveau.
Qu'est-ce qui ne vous plait pas dans ma solution ? Est-ce qu'elle ne fonctionne pas ? L'avez-vous essayée ?
Si vous trouvez une fonction toute faite (et portable) qui permet de se passer de ma solution : n'hésitez pas à m'en faire part, cela me permettra de simplifier certains de mes programmes.

Exact ta solution est celle que j'utilise en y ayant rajouter le cas ou argv[0] commence par './'.
Cela marche très bien sur mon Linux de dev mais j'ai peur du résultat une fois mon application lancée sur d'autres systèmes (AIX en particuier).

Merci

[DaZumba]

En gros tu penses qu'aller lire une variable d'environement dans laquel l'utilisateur aura rentré le chemin d'acces (ou a l'installation) est suffisant ? C'est vrai que cela simplifierait problème...

Même si mon problème n'est pas clair je ne suis pas issu du monde Unix et je ne connais pas la façon "standard" de faire cela.

Quitte a lire une variable d'environement pourquoi pas stocker le répertoire d'install dans mon fichier de configuration (passé en paramètre a l'application) alors ?

Il y a en effet quelques solutions typiques dans le monde Unix:
- un fichier de configuration a un endroit connu. C'est le principe utilise par les shells, par exemple, qui font lire des "runcom" files dans le home directory (.kshrc par exemple) ou dans un autre repertoire connu et fixe.
- une variable d'environnement qui donne la valeur du repertoire. Cette variable peut etre ajoutee a l'installation, ou l'application est "emballee" dans un script qui place cette variable.

Faire comme cela a plusieurs avantages:
- c'est simple
- cela donne une certaine liberte a l'utilisateur
- cela assure que le repertoire est accessible en ecriture (si ton application est installee dans /usr/bin ou /usr/local/bin, tu ne peux pas mettre a jour tes configurations)
- c'est conforme a la philosophie Unix.

[LeBigornot]

Il y a en effet quelques solutions typiques dans le monde Unix:
- un fichier de configuration a un endroit connu. C'est le principe utilise par les shells, par exemple, qui font lire des "runcom" files dans le home directory (.kshrc par exemple) ou dans un autre repertoire connu et fixe.
- une variable d'environnement qui donne la valeur du repertoire. Cette variable peut etre ajoutee a l'installation, ou l'application est "emballee" dans un script qui place cette variable.

Faire comme cela a plusieurs avantages:
- c'est simple
- cela donne une certaine liberte a l'utilisateur
- cela assure que le repertoire est accessible en ecriture (si ton application est installee dans /usr/bin ou /usr/local/bin, tu ne peux pas mettre a jour tes configurations)
- c'est conforme a la philosophie Unix.

Cette solution me plait beaucoup merci
Voila comment rester conforme et ne pas faire de chose inutile alors
Merci encore

[David.Schris]

Exact ta solution est celle que j'utilise en y ayant rajouter le cas ou argv[0] commence par './'.

Un ajout inutile à mon sens [1] car quand argv[0] commence par './' il entre dans la catégorie, déjà traitée, des argv[0] contenant un '/'.
Tu me diras peut-être : "oui, mais quand on colle le répertoire courant devant on obtient un truc comme '/repertoire/courant/./nomAppli' et ce n'est pas beau". Mais ce cas aussi est déjà traité par l'algo. que j'ai donné puisqu'il se termine par "vraiCheminAbsolu <- cheminCanonique(cheminAbsolu)"...
D'après ce que j'ai compris, tu peux donc (légèrement) simplifier ton algo.

Cela marche très bien sur mon Linux de dev mais j'ai peur du résultat une fois mon application lancée sur d'autres systèmes (AIX en particuier).

Là, tu as peut-être raison d'avoir peur.
Dans ton "stdlib.h" (sous linux) tu devrais pouvoir lire quelque-chose comme :

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
#ifdef  __USE_GNU
/* Return a malloc'd string containing the canonical absolute name of the
   named file.  The last file name component need not exist, and may be a
   symlink to a nonexistent file.  */
extern char *canonicalize_file_name (__const char *__name) __THROW;
#endif
 
#if defined __USE_BSD || defined __USE_XOPEN_EXTENDED
/* Return the canonical absolute name of file NAME.  The last file name
   component need not exist, and may be a symlink to a nonexistent file.
   If RESOLVED is null, the result is malloc'd; otherwise, if the canonical
   name is PATH_MAX chars or more, returns null with `errno' set to
   ENAMETOOLONG; if the name fits in fewer than PATH_MAX chars, returns the
   name in RESOLVED.  */
extern char *realpath (__const char *__restrict __name,
                       char *__restrict __resolved) __THROW;
#endif

Donc, cela s'annonce a priori plutôt bien pour realpath() sous AIX.
Une petite recherche dans la doc. d'AIX permet de vérifier que cette fonction est bien disponible (http://publib.boulder.ibm.com/infoce...2/realpath.htm).
Mais en poussant un peu plus loin, on tombe sur des choses du style :

realpath(3) is known to be broken on at least some versions of the following platforms:

• AIX
• NeXTStep

You cannot reliably detect this at configure time unless you have root privs.

On trouve aussi des discussions concernant le problème de l'implémentation de realpath() sous AIX :

I've built make-3.81beta3 with the IBM C compiler v7 and GCC 3.4.3.
All tests pass except functions/realpath

Mais rien de grave en fait : c'est une fonction simple à implémenter.
D'ailleurs, utiliser une version personnelle de realpath() semble être la solution utilisée dans certains cas :

> Does GNU make use libc's realpath or its own on AIX? (Check the test for
> realpath in config.log.) I am pretty sure it's AIX's realpath since I
> just tested GNU make's own fallback implementation and it work fine.
> So this is really a bug in AIX, not GNU make.

Yep, that's it. Thanks.

Cela peut sembler lourd d'inclure une version "de secours" d'une fonction, mais c'est parfois (souvent?) le prix à payer pour avoir une application portable.
Il m'est par exemple arrivé d'inclure des implémentations de strlcat() et strlcpy() dans des projets pour qu'ils puissent être compilés sous de relativement anciennes versions de linux...mais cela fonctionne (le script de configuration a son importance dans ces cas).

Pour le reste, je ne pense pas qu'il y ait de réels problèmes. Merci de nous tenir au courant si il y en a, c'est toujours bon à savoir.

Merci

A bientôt

[1] : et pas seulement à mon sens d'ailleurs : j'ai vu cette solution utilisée ailleurs...