Discussion :

[troumad]

Bonjour

J'aimerai en C, sous Windows et sous Linux (les méthodes sont sûrement différentes) savoir repérer où est l'exécutable. J'avais pensé, travailler à partir de argc , argv et le répertoire courant, mais je viens de penser qu'il existe des liens et le PATH ! Donc, cette méthode devient caduque
Mon but est de pouvoir accéder aux fichiers qui accompagnent mon exécutable comme des images ou d'autres fichiers que mon programme va lire.

En écrivant ceci, je pense à une machine à gaz...
1) chercher dans le path
2) vérifier si c'est un lien et si oui, recommencer le point 2 tant qu'on n'a pas le véritable fichier.

Question : ça donne quoi sous Linux si c'était un alias ?

Remarque : je n'ai pas envie d'inventer la roue... Ça devrait déjà exister non ?

[plxpy]

Bonjour

petite remarque qui ne répond pas à la totalité de ton message : tu ne peux pas laisser complètement tomber argc/argv car rien n'empêche un utilisateur de lancer un exécutable qui n'est pas dans un des répertoires de PATH (il suffit qu'il mette un chemin absolu/relatif correct).

Donc, PATH ou argc/argv ? les deux mon général !


autre remarque : sous Unix/Linux, le répertoire courant n'est pas, comme sous Windows (je crois) systématiquement "scanné" quand le système recherche un exécutable. Si "." n'est pas dans le PATH, et ben le système ne regarde pas le répertoire courant.

[ram-0000]

Sous Windows, tu as la fonction GetModuleFileName() qui retourne le chemin complet de l'exécutable. Il suffit d'enlever le nom du fichier et tu as le répertoire de ce fichier.

Par contre, tu te doutes bien que ce n'est pas transposable à Linux

[troumad]

plxpy a tout à fait raison pour le ".". Le reste, j'y avait déjà pensé.

Par contre, tu te doutes bien que ce n'est pas transposable à Linux

Est-ce possible que pour une fois Windows serait moins compliqué que Linux ?
Il doit bien exister quelque chose pour Linux

[plxpy]

Sous Linux, pour en faire le moins possible, j'utiliserais la sortie standard de "which" (popen en lecture de la commande "which" pour argv[0]) : ça t'évite de "parser" le PATH et si l'utilisateur a lancé l'outil via un chemin, c'est géré également (puisque le code s'exécute, c'est que le système à trouvé l'exécutable !!!)

Par contre, je crains que ça ne résolve pas le cas du lien symbolique.

Une petite fonction récursive avec, en paramètre, le retour de la commande (pas le code retour mais le chemin lu sur la sortie standard) et qui s'arrête quand le fichier n'est pas un lien symbolique, devrait faire l'affaire.

petit bémol à ce que j'ai écrit plus haut : j'ai raisonné en mode "ligne de commande". Si on lance l'appli (graphique, avec IHM) via un double-click, je ne sais pas trop ce qu'on récupère dans argv[0])

[troumad]

petit bémol à ce que j'ai écrit plus haut : j'ai raisonné en mode "ligne de commande". Si on lance l'appli (graphique, avec IHM) via un double-click, je ne sais pas trop ce qu'on récupère dans argv[0])

C'est aussi une question que je me pose !
Je vais essayer de tester cet après midi

Fait...

On récupère la commande mise dans l’icône => Ça revient au même que la ligne de commande.

[troumad]

Sous Windows, tu as la fonction GetModuleFileName() qui retourne le chemin complet de l'exécutable. Il suffit d'enlever le nom du fichier et tu as le répertoire de ce fichier.

Il doit y avoir des paramètres à passer au compilateur pour prendre en compte winbase.h qui est utile pour cette fonction !
J'ai plein d'erreur lors de la compilation de winbase.h

[ram-0000]

Il doit y avoir des paramètres à passer au compilateur pour prendre en compte winbase.h qui est utile pour cette fonction !

Non non, il faut inclure <windows.h> (et pas winbase.h)

[troumad]

Oui, c'est ce que je viens de voir et ça me fout tout en l'air avec des doublons de #define qui n'ont plus le même sens qui moi !
Quelle idée insensée de mettre par exemple

Code :

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

#define LONG long;

Avec cette bibliothèque, l'exécutable est passé de 246 ko à 535 ko !