salut les amis  je sais pas pourquoi j'arrive pas à ouvrir une fichier en langage C en utilisant la fonction fopen() 

ce qui m'a empêché d'avancer au cours S'il vous plait aidez mois 

voila le code source et  le dossier du projet :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main()
{
   FILE* fichier = NULL;
    fichier = fopen("test.text", "r");
  if(fichier == NULL)
  {
      printf("false");
  }
  else
  {
      printf("true");
  }
}

Bonjour ! Tu veux ouvrir en lecture le fichier "test.text", celui-ci dois donc exister. Sur la capture d'écran, il n'a pas l'air d'exister.

OUI OUI je sais au début le fichier "test.text" s'était dans le dossier du projet et quand l'ouverture n'a pas réussi je l'ai déplace 

dans le dossier "bin" apparu dans la capture d'écran qui contient le .exe 

NASRODIN : ouvre ton propre sujet, là tu parasites celui de issaElyaakoubu1.

-----

Et si tu remplaces "test.text" par son nom complet (avec le chemin), genre "C:\Users\Truc\Projet1\Bin\test.text" (ou quelque chose comme ça) ?

je viens d'essayer  cette méthode mais elle  n'a pas marché 

-
Edité par issaELyaakoubi1 8 septembre 2018 à 17:15:01

Elle devrait. Tu as bien tapé le chemin exact, tu as tout vérifié ?

Quand tu dis que ça ne marche pas, on est bien d'accord que le programme affiche "false" ?

Le fichier existe, tu as tout vérifié ? Est-ce que ton explorateur est réglé pour afficher ou pour cacher les extensions ?

merci pour ces questions 

mon explorateur est réglé pour cacher les extensions 

et le chemin je l'ai pris a partir d'un navigateur 

"file:///C:/Users/pro/Desktop/fopen/bin/Debug/test.txt"

Le fichier s'appelle-t-il "test.text" ou "test.txt" ? Car dans ton programme tu as écrit :

fichier = fopen("test.text", "r");

Le chemin qu'a donné le navigateur n'a pas la bonne syntaxe, il me semble qu'il faut utiliser la syntaxe de Windows : "C:\Users\pro\Desktop\fopen\bin\Debug\test.txt"

Et puis en langage C, le caractère '\' s'affiche par '\\' je crois (à confirmer), donc j'essaierais bien :

fichier = fopen("C:\\Users\\pro\\Desktop\\fopen\\bin\\Debug\\test.txt", "r");

Dans l'explorateur, le fichier s'affiche comme "test" tout court, c'est bien ça ? (Je pose la question au cas où il s'appellerait "test.txt.txt", j'ai déjà vu le coup sur le forum...)

Il faudrait aussi être clair sur la position des différents fichiers : "test.txt" est dans le sous-répertoire "Debug", mais je vois dans ta première capture d'écran un "main" tout court, peut-être un "main.exe" (puisque l'explorateur cache les extensions) qui n'est pas dans Debug mais dans le répertoire-grand-père. Du coup j'essaierais bien :

fichier = fopen("Bin\\Debug\\test.txt", "r");

En tout cas, si tu sais où est "test.txt", il faut aussi que tu saches où est l'exécutable. Il est où ?

-
Edité par robun 8 septembre 2018 à 17:58:18

Ah, du coup je me suis trompé en mettant des \ comme séparateurs des répertoires, c'est pourtant ainsi que Windows procède, mais je suppose que c'est le compilateur C qui décide...

Pour moi, ce genre de problème est un des défauts des environnements de développement. En fait, lorsque j'avais commencé à suivre le cours de C avec Code::Blocks (puisque c'est lui qui était proposé), c'est en voyant tous ces sous-répertoires Bin, Debug, etc. qui m'embrouillaient que j'ai décidé de laisser tomber les environnements de développements. Désormais, j'ai donc choisi de compiler en ligne de commande, « à l'ancienne ». Ainsi, je sais où sont mes fichiers et, surtout, il n'y a personne pour me créer des tonnes de sous-répertoires qui m'embrouillent... Lors de mon apprentissage, ça m'a permis de me concentrer sur l'apprentissage du langage, pas sur l'apprentissage de l'IDE.

-
Edité par robun 8 septembre 2018 à 22:44:47

robun a écrit:

Désormais, j'ai donc choisi de compiler en ligne de commande, « à l'ancienne ». Ainsi, je sais où sont mes fichiers et

Un autre gros avantage de la ligne de commande est que l'on sait toujours quel est le répertoire de travail courant (current working directory), et donc on sait toujours où le système commence ses recherches lorsqu'on lui donne un chemin relatif (comme "monFichier.txt" ou "monDir/monFichier.txt").

merci à tous 😊😊

robun a écrit:

Ah, du coup je me suis trompé en mettant des \ comme séparateurs des répertoires, c'est pourtant ainsi que Windows procède, mais je suppose que c'est le compilateur C qui décide...

Non c'est le système d'exploitation, dans sa partie "systemes de fichiers".

* Il faut savoir que, pour des raisons historiques (1) la présentation habituelle des chemins d'accès, sous windows se fait avec des \

     C:\truc\machin.txt

Ce qui est un peu agaçant en C / C++, où le caractère \ est spécialisé, et doit donc être désepecialisé par un autre \ quand il figure dans une chaine

char *  chemin = "C:\\truc\\machin.txt";
FILE * fichier = fopen(chemin, "r");

* mais pour d'autres raisons historiques (2), le caractère / est également utilisable comme séparateur dans les chemins d'accès

char * chemin = "C:/truc/machin.txt";

PS: savoir  où est le "current directory" quand on fait exécuter un programme depuis un IDE est toujours une galère, quand on utilise des fichiers avec un chemin relatif. Pour ne pas s'embêter, le plus simple est de faire un premier programme qui ECRIT un fichier là où il s'exécute. Après y a plus qu'à chercher où il a été créé.

Sais pas pourquoi, les gens veulent toujours commencer par un programme qui LIT un fichier....

(1) parce que les premières versions de MS-DOS ne gèraient pas les répertoires (comme CP/M), et que le caractère / a été choisi pour désigner les options des commandes, comme  dans  FORMAT C: /Q  (n'essayez pas chez vous). Après, quand il a fallu gérer les chemins d'accès...

(2) parce que le rêve de Bill Gates, qui n'espérait pas devenir maitre du monde avec MS-DOS, était de bazarder ce truc merdique plein de trous pour fournir à la place un vrai système d'exploitation : XENIX (1979).  Et donc faciliter la compatibilité des applications. Mais bon, il s'est aperçu que si il lachait MS-DOS d'un coup, les clients n'accepteraient pas tous de racheter des versions (qui n'existaient pas) pour Xenix de leurs applications, et qu'ils se barreraient chez la concurrence.  Donc Microsoft s'est retrouvé obligé de faire évoluer les choses en douceur.  Windows en surcouche, puis suppression de MS-DOS sous Windows. Ca a pris du temps, et les clients ont de toutes façons raqué parce qu'acheter une machine implique de changer de version de systeme, et pousse à changer de version de logiciel. Mais dans une certaine continuité.

-
Edité par michelbillaud 9 septembre 2018 à 19:47:03

michelbillaud a écrit:

PS: savoir  où est le "current directory" quand on fait exécuter un programme depuis un IDE est toujours une galère, quand on utilise des fichiers avec un chemin relatif. Pour ne pas s'embêter, le plus simple est de faire un premier programme qui ECRIT un fichier là où il s'exécute. Après y a plus qu'à chercher où il a été créé.

Une autre possibilité est d'utiliser getcwd()

#include <io.h>
#include <stdio.h>

int main(void) {
	char curdir[512];
	
	getcwd(curdir,sizeof(curdir));
	printf("curdir: %s\n",curdir);
	
	return(0);
}

Code minimaliste, juste pour afficher le répertoire (à vérifier, chez moi, gcc 6.3.0 et win7 ça fonctionne):

int main(void) {
	
	printf("curdir: %s\n",getcwd(NULL,0));
	
	return(0);
}

Edit: ce dernier code fonctionne, mais provoquera une perte mémoire: man getcwd() ).

-
Edité par edgarjacobs 10 septembre 2018 à 0:20:17

Merci pour ces précisions, c'est très intéressant !

edgarjacobs a écrit:

michelbillaud a écrit:

PS: savoir  où est le "current directory" quand on fait exécuter un programme depuis un IDE est toujours une galère, quand on utilise des fichiers avec un chemin relatif. Pour ne pas s'embêter, le plus simple est de faire un premier programme qui ECRIT un fichier là où il s'exécute. Après y a plus qu'à chercher où il a été créé.

Une autre possibilité est d'utiliser getcwd()

#include <io.h>
#include <stdio.h>

int main(void) {
	char curdir[512];
	
	getcwd(curdir,sizeof(curdir));
	printf("curdir: %s\n",curdir);
	
	return(0);
}

Code minimaliste, juste pour afficher le répertoire (à vérifier, chez moi, gcc 6.3.0 et win7 ça fonctionne):

int main(void) {
	
	printf("curdir: %s\n",getcwd(NULL,0));
	
	return(0);
}

Edit: ce dernier code fonctionne, mais provoquera une perte mémoire: man getcwd() ).

Un coup d'oeil à la norme posix 2017 : http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html

• Une taille raisonnable pour le tampon est la constante PATH_MAX, qui est la longueur max de la chaine qu'on peut donner à open ou fopen pour indiquer un chemin d'accès relatif ou absolu (4096 sous linux). https://eklitzke.org/path-max-is-tricky 
• Mais il peut y avoir des chemins d'accès plus longs, ce qui provoque des erreurs ERANGE, une stratégie possible est alors d'allouer des buffers de plus en plus grands, jusqu'à ce que ça veuille bien marcher (exemple de la doc posix)
• le comportement est indéfini si le premier paramètre est le pointeur NULL. C'est ce que permet Linux (GNU libc), mais ce n'est pas portable.

-
Edité par michelbillaud 10 septembre 2018 à 10:11:25

@RedaKamel Bonjour, merci de ne pas déterrer d'ancien sujet.

Déterrage

Citation des règles générales du forum :

Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.

Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre.
En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.

Au lieu de déterrer un sujet il est préférable :

• soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
• soit de créer un nouveau sujet décrivant votre propre contexte
• ne pas répondre à un déterrage et le signaler à la modération

Je ferme ce sujet. En cas de désaccord, me contacter par MP.