Discussion :

[Fukasaya]

Bonjour,

Je rencontre actuellement un problème. Je souhaite faire une application (en langage C) compatible sur Windows, Linux et MacOS. Mon application doit pouvoir lire et ouvrir des fichiers.

Mon soucis se pose sous MacOS. J'aimerai lorsque je fais un fopen("fichier.txt","r") qu'il ouvre le fichier qui se situe dans le dossier de mon application. Hélas pour une raison qui m'échappe, il cherche toujours le fichier dans "User/NomDuCompte" au lieu de le chercher dans le dossier de mon application.

Ceci est très gênant, j'aimerai ne pas utiliser de chemin absolu. Hors MacOS n'en fait qu'à sa tête

Même si je doute que le code vous soit utile, je vous le donne tout de même.

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
24
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
int main()
{
 
    FILE* fichier = NULL;
 
    // Me permet de savoir sur quel dossier je travaille actuellement
    char chemin[100];
    getcwd(chemin);
    printf("%s\n",chemin); // Affiche sous MacOS Users/NomDeCompte
 
 
    fichier = fopen("fichier.txt","r+");
 
    if(fichier != NULL)
        printf("Ouverture reussie !\n"); // Si fichier.txt se trouve dans Users/NomDeCompte
    else
        printf("Fichier inexistant !\n");
 
    return 0;
}

Je vous remercie pour votre aide.

[Médinoc]

Le "répertoire courant" et le "répertoire où se trouve l'exécutable" sont deux choses différentes.

• Sous *n*x, il me semble qu'il n'existe aucun moyen fiable à 100% de connaître la seconde information; ce qui marche sur un unixoïde peut ne pas marcher sur un autre.
• Sous Windows, c'est très facile.

[Fukasaya]

Merci pour la réponse.

Mais alors, comment font les applications (sous MacOS) pour trouver les fichiers qu'ils utilisent quelque soit le répertoire où elles sont installées.

Ils utilisent un autre langage ? Une librairie spécifique ?

[Jean-Marc.Bourguet]

Il est possible -- probable meme -- que MacOS ait des conventions differentes des conventions habituelles sous Unix.

La technique "normale" est de recuperer toute l'info dont on a besoin d'un (ou plusieurs) fichier(s) de configuration place(s) a un endroit fixe (generalement sous /etc/, parfois aussi /usr/etc, /opt/etc, $HOME/.<app>rc; si plusieurs endroits sont cherches, le fait qu'il y ait fusion ou pas et la priorite varie) modifiable par une option sur la ligne de commande ou une variable d'environnement -- et a la compilation quand c'est distribue sous forme de sources.

C'est assez peu pratique pour des applications distribuees sous forme de binaires, car l'utilisation de variables d'environnement est alors quasiment obligatoire. La deuxieme technique est donc l'utilisation de scripts shells, qui ont le chemin par lequel ils ont ete lances dans l'argument 0, pour lancer l'application. Parfois ces scripts ont leur chemin d'installation hardcode lors de l'installation. Il y a d'autres raisons qui font que c'est souvent de toute maniere necessaire -- il faut mettre aussi le chemin pour les bibliotheques dynamiques, il faut choisir l'executable 32 ou 64 bits. Le script communique avec l'executable soit par variable d'environnement, soit par argument.

La troisieme technique est d'utiliser argv[0] et la valeur de getenv("PATH") pour retrouver l'executable (si argv[0] a un "/", il contient un chemin absolu ou relatif au repertoire courant, sinon, c'est un nom a chercher dans le PATH) -- on peut arriver a lancer l'appli sans qu'elle retrouve ses petits, mais il faut quand meme le chercher et la position disant que celui qui a un probleme dans ce cas a eu ce qu'il voulait se defend assez bien.

La quatrieme technique est d'utiliser des particularites du Unix utilise (/proc/self/exe pour Linux, /proc/<pid>/path/a.out pour Sun) pour retrouve le chemin.

Il faut faire attention si on recupere le chemin par lequel on a ete lance (par n'importe quelle maniere, script, parcours du PATH, mecanisme propre a l'OS), parce qu'avec les liens symboliques, ce peut tres bien ne pas etre le chemin d'installation: il est courant pour les administrateurs de vouloir fournir un repertoire avec des liens pointant vers le chemin officiel d'installation des applications (ca ne fait qu'un repertoire a chercher plutot que des dizaines, le changement de la version "officielle" a utiliser se fait en changeant simplement quelques liens plutot que de changer les environnements de tout le monde).

Ma recommandation (pour unix en general, a nouveau MacOS peut avoir ses propres conventions): le programme compile utilise une variable d'environnement pour connaitre son chemin d'installation (et eventuellement une ou plusieurs autres techniques si elle n'est pas definie) et utilise un script qui defini cette variable d'environnement a partir de argv[0] puis lance ton executable.