[ansi C] directory listing
hibou57
Messages postés
132
Statut
Membre
-
Aghaster Messages postés 26 Statut Membre -
Aghaster Messages postés 26 Statut Membre -
Hi all,
Une carance dans la bibliothèque standard ansi C.
Il n'y a pas de fonctions/structure standard avec le C ansi, pour faire lister les entrées d'un repertoire (je ne sais même pas si la fonction stat est standard).
Il y a findfirt et findnext pour dos/windows, qui renvoie une structure bien renseignée, avec les attributs du fichier, la taille, date de création, modification, accés, ainsi que le nom de l'entrée. Parfait, c'est une fonction trés complète, rien à lui reprocher. Mais les fonctions dos/windows ne sont pas réputé pour être des standard.
Il y a opendir/readir pour unix/linux, qui renvoie une structure dirent. Malheureusement, cette structure est pauvre en information, et ne contient ni les attributs, ni la taille, ni les dates d'accés/modification du fichier. En bref, rien (à ce demandé comment les concepteur de unix/linux on put se contenter de si peu).
Je suis désagréablement surpris : comment ceux/celles qui ont concu le standard ansi ont-ils/elles puent ne même pas penser à cette fonction fondamental et vitale qu'est l'accès à un repertoire ?
Je crois qu'il va donc falloir composé... quite à me créer ce que je considererai comme « mon standard ». Je pense me baser sur les fonctions de dos/windows, parce que ce sont de loin les plus complètes et les plus logiques. Mais j'aurais aimé quelque chose qui soit compatible posix par exemple, et qui soit au moins aussi fonctionelle que les fonctions de dos/windows.
Quelqu'un(e) a des idées à ce sujet ?
(il s'agit là plutôt d'une discussion, car je ne pense pas qu'il y ait *une* réponse exacte)
Merci beaucoup
Une carance dans la bibliothèque standard ansi C.
Il n'y a pas de fonctions/structure standard avec le C ansi, pour faire lister les entrées d'un repertoire (je ne sais même pas si la fonction stat est standard).
Il y a findfirt et findnext pour dos/windows, qui renvoie une structure bien renseignée, avec les attributs du fichier, la taille, date de création, modification, accés, ainsi que le nom de l'entrée. Parfait, c'est une fonction trés complète, rien à lui reprocher. Mais les fonctions dos/windows ne sont pas réputé pour être des standard.
Il y a opendir/readir pour unix/linux, qui renvoie une structure dirent. Malheureusement, cette structure est pauvre en information, et ne contient ni les attributs, ni la taille, ni les dates d'accés/modification du fichier. En bref, rien (à ce demandé comment les concepteur de unix/linux on put se contenter de si peu).
Je suis désagréablement surpris : comment ceux/celles qui ont concu le standard ansi ont-ils/elles puent ne même pas penser à cette fonction fondamental et vitale qu'est l'accès à un repertoire ?
Je crois qu'il va donc falloir composé... quite à me créer ce que je considererai comme « mon standard ». Je pense me baser sur les fonctions de dos/windows, parce que ce sont de loin les plus complètes et les plus logiques. Mais j'aurais aimé quelque chose qui soit compatible posix par exemple, et qui soit au moins aussi fonctionelle que les fonctions de dos/windows.
Quelqu'un(e) a des idées à ce sujet ?
(il s'agit là plutôt d'une discussion, car je ne pense pas qu'il y ait *une* réponse exacte)
Merci beaucoup
A voir également:
- [ansi C] directory listing
- Directory list & print - Télécharger - Divers Utilitaires
- Directory opus - Télécharger - Gestion de fichiers
- Faire un listing - Guide
- Remove empty directory - Télécharger - Nettoyage
- Directory report - Télécharger - Gestion de fichiers
5 réponses
Extrait de man 2 stat
et
Cela donne déjà pas mal d'information , non ?
The stat() and fstat() calls conform to SVr4, SVID, POSIX, X/OPEN,
4.3BSD. The lstat() call conforms to 4.3BSD and SVr4.
et
int stat(const char *path, struct stat *buf);
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* inode number */
mode_t st_mode; /* protection */
nlink_t st_nlink; /* number of hard links */
uid_t st_uid; /* user ID of owner */
gid_t st_gid; /* group ID of owner */
dev_t st_rdev; /* device ID (if special file) */
off_t st_size; /* total size, in bytes */
blksize_t st_blksize; /* blocksize for filesystem I/O */
blkcnt_t st_blocks; /* number of blocks allocated */
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
Cela donne déjà pas mal d'information , non ?
Je pense me baser sur les fonctions de dos/windows, parce que ce sont de loin les plus complètes et les plus logiques
fonctions de dos/windows?!
Peux tu faire une énumération de ces fonctions les plus complètes et les plus logiques.
fonctions de dos/windows?!
Peux tu faire une énumération de ces fonctions les plus complètes et les plus logiques.
Re,
la structure donnée dans le message précédent le tiens ne comporte pas le nom de l'élement... ça me semble pourtant fondamental.
Pour le nom d'élément c'est normal. stat envoie des infos sur un fichier indiqué (par son nom).
Tu peux utiliser opendir, readdir ensembe avec stat,fstat,lstat pour obtenir ce que tu veux.
la structure donnée dans le message précédent le tiens ne comporte pas le nom de l'élement... ça me semble pourtant fondamental.
Pour le nom d'élément c'est normal. stat envoie des infos sur un fichier indiqué (par son nom).
Tu peux utiliser opendir, readdir ensembe avec stat,fstat,lstat pour obtenir ce que tu veux.
D'ac,
donc ça confirme ce que je savais déjà, à part les structure spécifique à dos/windows, il n'existe pas de structure standard réunissant toutes les informations sur un fichier.
En fait je cherchais une structure, qui servent d'élément pour un tableau qui représenterais le listing d'un repertoire (c'est pour un client ftp fait maison). Et même si je pouvais bien sure créer ma propre structure, je me disais que si un telle structure existe déjà en standard, alors autant l'utiliser. Ce que je vais donc faire, c'est choisir la structure utilisé par stat, et lui ajouté à la fin, un tableau de caractères pour le nom du fichier. J'aurai quelques chose qui ressemble à la structure utilisé par windows, mais qui ressemblera plus à quelque chose de standard.
Le problème qui se pose maintenant, si je ne veux pas délocaliser le nom du fichier (en utilisant un pointeur sur le nom par exemple), c'est de trouver un longueure limite au nom de fichier. Je crois que la limite théorique est de 255 caractères... mais c'est en fait la limite pour la longeur d'une spécification de chemin absolue... et par conscéquence, celle d'un nom de fichier sans spécification de chemin (même si alors un tel nom de fichier ne pourrait jamais être contenu dans un chemin).
Certains système unix sont par contre eux, limité à 32 caractères pour un nom de fichier (si je ne me trompe pas), mais cette limite n'existe pas sous linux (ni sous windows).
Je pourrais prendre un valeur raisonnable, comme 64 caractère (parce que je ne vois pas souvent de nom de fichier plus longs, seuls ceux générés automatiquement pour l'enregistrement de page web sont parfois aussi long). Mais en même temps, une telle limite... risquerais toujours d'être dépassé.
Ca m'ennuit, mais je crois que ça va être difficile de faire mieux. D'autant qu'à être aussi pointilleux, je vais finir par ennervé du monde, je le sent... je me suis déjà pris la tête avec un artiste qui ne connais rien à la programmation, ici même... je ne fait pas que des ami(e)s lol .
Merci encore d'avoir répondu (et c'est vrai, pour l'erreur précédente, j'en ai rie quand tu me l'a fait remarqué).
donc ça confirme ce que je savais déjà, à part les structure spécifique à dos/windows, il n'existe pas de structure standard réunissant toutes les informations sur un fichier.
En fait je cherchais une structure, qui servent d'élément pour un tableau qui représenterais le listing d'un repertoire (c'est pour un client ftp fait maison). Et même si je pouvais bien sure créer ma propre structure, je me disais que si un telle structure existe déjà en standard, alors autant l'utiliser. Ce que je vais donc faire, c'est choisir la structure utilisé par stat, et lui ajouté à la fin, un tableau de caractères pour le nom du fichier. J'aurai quelques chose qui ressemble à la structure utilisé par windows, mais qui ressemblera plus à quelque chose de standard.
Le problème qui se pose maintenant, si je ne veux pas délocaliser le nom du fichier (en utilisant un pointeur sur le nom par exemple), c'est de trouver un longueure limite au nom de fichier. Je crois que la limite théorique est de 255 caractères... mais c'est en fait la limite pour la longeur d'une spécification de chemin absolue... et par conscéquence, celle d'un nom de fichier sans spécification de chemin (même si alors un tel nom de fichier ne pourrait jamais être contenu dans un chemin).
Certains système unix sont par contre eux, limité à 32 caractères pour un nom de fichier (si je ne me trompe pas), mais cette limite n'existe pas sous linux (ni sous windows).
Je pourrais prendre un valeur raisonnable, comme 64 caractère (parce que je ne vois pas souvent de nom de fichier plus longs, seuls ceux générés automatiquement pour l'enregistrement de page web sont parfois aussi long). Mais en même temps, une telle limite... risquerais toujours d'être dépassé.
Ca m'ennuit, mais je crois que ça va être difficile de faire mieux. D'autant qu'à être aussi pointilleux, je vais finir par ennervé du monde, je le sent... je me suis déjà pris la tête avec un artiste qui ne connais rien à la programmation, ici même... je ne fait pas que des ami(e)s lol .
Merci encore d'avoir répondu (et c'est vrai, pour l'erreur précédente, j'en ai rie quand tu me l'a fait remarqué).
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
