si je cr=E9e "=E0 la main" au terminal, une dir (ou un fichier) contenant
des caract=E8res Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) =E7a me dit que le fichier n'existe pas.
j'imagine comme en entr=E9e du stat c'est un char * qui est demand=E9, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
y aurait'il une lib de "wstat" (stat en wchar_t) ???
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caract=E8res Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
Le 14/08/07 16:37, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche » a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit. Evidemment, cela n'est pas franchement pratique pour gérer des accents, et historiquement chaque administrateur adoptait un encodage différent (ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple, un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets qui ne sont pas des encodage utf-8 valide, et que MacOSX gère parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/08/07 16:37, dans <87643i89mv.fsf@thalassa.informatimago.com>,
« Pascal Bourguignon » <pjb@informatimago.com> a écrit :
Eric Levenez <news@levenez.com> writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$1@news.httrack.net>, « Xavier Roche »
<xroche@free.fr.NOSPAM.invalid> a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple,
un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets
qui ne sont pas des encodage utf-8 valide, et que MacOSX gère
parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en
ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32
(qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface
disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS
X qui va faire la conversion en ce qui va bien.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 14/08/07 16:37, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche » a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit. Evidemment, cela n'est pas franchement pratique pour gérer des accents, et historiquement chaque administrateur adoptait un encodage différent (ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple, un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets qui ne sont pas des encodage utf-8 valide, et que MacOSX gère parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Pascal Bourguignon
Xavier Roche writes:
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Seulement le fichier en question se trouve sur un volume HFS+.
Un volume NFS contenant un file system ext3 est monté sur un volume HFS+. Dans ce volume NFS on monte un volume HFS+, et dans ce dernier encore un autre volume ext3. Une séquence d'octet invalide pour UTF-8 peut être rejetée, mais uniquement quand elle fait parti d'un nom qui doit être résolu sur un volume HFS+.
Les octets indiqués par ^^ pourraient contenir une séquence invalide pour UTF-8, et cependant on peut atteindre le fichier dénoté. Enfin, à condition que le programme ne soit pas idiot, et n'essaye pas de tester lui-même la validité de la séquence d'octet (c'est à dire, qu'il n'utilise pas une chaine unicode pour manipuler les chemins POSIX).
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Seulement le fichier en question se trouve sur un volume HFS+.
Un volume NFS contenant un file system ext3 est monté sur un volume
HFS+. Dans ce volume NFS on monte un volume HFS+, et dans ce dernier
encore un autre volume ext3. Une séquence d'octet invalide pour UTF-8
peut être rejetée, mais uniquement quand elle fait parti d'un nom qui
doit être résolu sur un volume HFS+.
Les octets indiqués par ^^ pourraient contenir une séquence invalide
pour UTF-8, et cependant on peut atteindre le fichier dénoté. Enfin,
à condition que le programme ne soit pas idiot, et n'essaye pas de
tester lui-même la validité de la séquence d'octet (c'est à dire,
qu'il n'utilise pas une chaine unicode pour manipuler les chemins
POSIX).
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Un open() avec une chaîne invalide renvoi donc un code d'erreur ?
Seulement le fichier en question se trouve sur un volume HFS+.
Un volume NFS contenant un file system ext3 est monté sur un volume HFS+. Dans ce volume NFS on monte un volume HFS+, et dans ce dernier encore un autre volume ext3. Une séquence d'octet invalide pour UTF-8 peut être rejetée, mais uniquement quand elle fait parti d'un nom qui doit être résolu sur un volume HFS+.
Les octets indiqués par ^^ pourraient contenir une séquence invalide pour UTF-8, et cependant on peut atteindre le fichier dénoté. Enfin, à condition que le programme ne soit pas idiot, et n'essaye pas de tester lui-même la validité de la séquence d'octet (c'est à dire, qu'il n'utilise pas une chaine unicode pour manipuler les chemins POSIX).
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Pascal Bourguignon
Eric Levenez writes:
Le 14/08/07 16:37, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche » a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit. Evidemment, cela n'est pas franchement pratique pour gérer des accents, et historiquement chaque administrateur adoptait un encodage différent (ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple, un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets qui ne sont pas des encodage utf-8 valide, et que MacOSX gère parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le! Tu peux écrire un petit programme unix, tu le verras bien! open(2) prend une séquence d'octet sur MacOSX comme sur tout système POSIX. La façon dont cette séquence d'octet est interprétée depends seulement de POSIX et des file systems par lesquels on passe. En l'occurence, si on a monté un volume ext3 ou NFS, on a droit à toutes les combinaisons octets (hormis 0 et 47).
Sur MacOSX, comme sur tout système unix, il n'y a qu'une seule interface: le syscall open(2), et celui ci prend une séquence d'octet.
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Eric Levenez <news@levenez.com> writes:
Le 14/08/07 16:37, dans <87643i89mv.fsf@thalassa.informatimago.com>,
« Pascal Bourguignon » <pjb@informatimago.com> a écrit :
Eric Levenez <news@levenez.com> writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$1@news.httrack.net>, « Xavier Roche »
<xroche@free.fr.NOSPAM.invalid> a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit.
Evidemment, cela n'est pas franchement pratique pour gérer des accents,
et historiquement chaque administrateur adoptait un encodage différent
(ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale
du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas
uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence
UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple,
un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets
qui ne sont pas des encodage utf-8 valide, et que MacOSX gère
parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en
ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32
(qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface
disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS
X qui va faire la conversion en ce qui va bien.
Essaye le! Tu peux écrire un petit programme unix, tu le verras bien!
open(2) prend une séquence d'octet sur MacOSX comme sur tout système
POSIX. La façon dont cette séquence d'octet est interprétée depends
seulement de POSIX et des file systems par lesquels on passe. En
l'occurence, si on a monté un volume ext3 ou NFS, on a droit à toutes
les combinaisons octets (hormis 0 et 47).
Sur MacOSX, comme sur tout système unix, il n'y a qu'une seule
interface: le syscall open(2), et celui ci prend une séquence d'octet.
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Le 14/08/07 16:37, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Le 14/08/07 15:35, dans <f9sb37$5ai$, « Xavier Roche » a écrit :
Sous Linux (/Unix), un nom de fichier est une chaîne opaque 8-bit. Evidemment, cela n'est pas franchement pratique pour gérer des accents, et historiquement chaque administrateur adoptait un encodage différent (ISO-8859-1 pour nous, SHIFT_JIS côté soleil levant, etc.) via la locale du système (man locale)
Sur l'unix Mac OS X, un nom de fichier est une chaîne UTF-8 et pas uniquement une chaîne "opaque". Le système va donc rejeter toutes séquence UTF-8 illégale.
Ceci est faux.
Ah, les petites phrases définitives comme Usenet seul sait les créer... :-)
Je dirais même mieux : ceci est faux.
Ce n'est pas sur l'unix MacOSX, c'est sur le file system HFS+.
Non. En interne HFS+ utilise l'UTF-16, et pas l'UTF-8.
Quand on monte un volume qui n'est pas HFS+ sur MacOSX (par exemple, un volume ext3 sur Linux via NFS), on y trouve des séquences d'octets qui ne sont pas des encodage utf-8 valide, et que MacOSX gère parfaitement comme tout bon système POSIX.
Cela est fait par une couche d'adaptation en dessous qui traduit l'UTF-8 en ce qui va bien pour le système de fichiers.
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le! Tu peux écrire un petit programme unix, tu le verras bien! open(2) prend une séquence d'octet sur MacOSX comme sur tout système POSIX. La façon dont cette séquence d'octet est interprétée depends seulement de POSIX et des file systems par lesquels on passe. En l'occurence, si on a monté un volume ext3 ou NFS, on a droit à toutes les combinaisons octets (hormis 0 et 47).
Sur MacOSX, comme sur tout système unix, il n'y a qu'une seule interface: le syscall open(2), et celui ci prend une séquence d'octet.
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Pascal Bourguignon
unbewust writes:
[...]
LC_CTYPE=fr_FR.UTF-8
OK, merci, c'est exactement ce que j'ai par défaut sur ma bécanne... [...] mon source est aussi en UTF-8
Ok, alors peut être que le problème est une question de normalisation unicode. Peut être que l'éditeur n'utilise pas la même normalisation, et il faut alors le faire explicitement dans le programme C.
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
unbewust <yvon.thoraval@gmail.com> writes:
[...]
LC_CTYPE=fr_FR.UTF-8
OK, merci, c'est exactement ce que j'ai par défaut sur ma bécanne...
[...]
mon source est aussi en UTF-8
Ok, alors peut être que le problème est une question de normalisation
unicode. Peut être que l'éditeur n'utilise pas la même normalisation,
et il faut alors le faire explicitement dans le programme C.
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
OK, merci, c'est exactement ce que j'ai par défaut sur ma bécanne... [...] mon source est aussi en UTF-8
Ok, alors peut être que le problème est une question de normalisation unicode. Peut être que l'éditeur n'utilise pas la même normalisation, et il faut alors le faire explicitement dans le programme C.
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Eric Levenez
Le 14/08/07 19:35, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/08/07 19:35, dans <87odha6mui.fsf@thalassa.informatimago.com>,
« Pascal Bourguignon » <pjb@informatimago.com> a écrit :
Eric Levenez <news@levenez.com> writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32
(qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface
disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS
X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 14/08/07 19:35, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Pascal Bourguignon
Eric Levenez writes:
Le 14/08/07 19:35, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
Alors on ne doit pas avoir le même MacOSX. -- __Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Eric Levenez <news@levenez.com> writes:
Le 14/08/07 19:35, dans <87odha6mui.fsf@thalassa.informatimago.com>,
« Pascal Bourguignon » <pjb@informatimago.com> a écrit :
Eric Levenez <news@levenez.com> writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32
(qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface
disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS
X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
Alors on ne doit pas avoir le même MacOSX.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Le 14/08/07 19:35, dans , « Pascal Bourguignon » a écrit :
Eric Levenez writes:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Essaye le!
C'est déjà fait, bien sûr. Errno 22.
Tu peux écrire un petit programme unix, tu le verras bien!
J'ai testé et cela marche comme je l'ai dit.
Alors on ne doit pas avoir le même MacOSX. -- __Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Antoine Leca
En news:, unbewust va escriure:
si je crée "à la main" au terminal, une dir (ou un fichier) contenant des caractères Unicode et que je fais un stat dessus (depuis C en castant le path en (char *) ça me dit que le fichier n'existe pas.
Essaye opendir() and co., ou fnmatch(), pour obtenir le «vrai» nom du fichier.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que les routines de comparaisons de string internes n'utilisent pas les wchar_t comme wcscmp ???
stat(2) est un appel système (parfois enrobé dans une très fine couche), donc les routines internes en question sont celles du noyau. Qui n'ont que peu de chances d'être wcscmp(3).
y aurait'il une lib de "wstat" (stat en wchar_t) ???
Peut-être sur ta bécane. Chez moi, non (OS=Minix). Ici, oui (OS=NT; s'appelle _wstat(), de fait).
ce que je trouve curieux est que le mkdir marche, le touch aussi avec des caractères Unicode, mais pas le stat, j'en ai eu la confirmation par un mdls sur les dits rep et/ou fichier...
touch() n'est pas à ma connaissance une fonction C normalisée ou même répandue, j'ai idée que l'on mélange des choses qui n'ont pas grand'chose à voir entre elles.
Antoine
En news:1187097417.058018.251070@57g2000hsv.googlegroups.com,
unbewust va escriure:
si je crée "à la main" au terminal, une dir (ou un fichier) contenant
des caractères Unicode et que je fais un stat dessus (depuis C en
castant le path en (char *) ça me dit que le fichier n'existe pas.
Essaye opendir() and co., ou fnmatch(), pour obtenir le «vrai» nom du
fichier.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que
les routines de comparaisons de string internes n'utilisent pas les
wchar_t comme wcscmp ???
stat(2) est un appel système (parfois enrobé dans une très fine couche),
donc les routines internes en question sont celles du noyau.
Qui n'ont que peu de chances d'être wcscmp(3).
y aurait'il une lib de "wstat" (stat en wchar_t) ???
Peut-être sur ta bécane. Chez moi, non (OS=Minix). Ici, oui (OS=NT;
s'appelle _wstat(), de fait).
ce que je trouve curieux est que le mkdir marche, le touch aussi avec
des caractères Unicode, mais pas le stat, j'en ai eu la confirmation
par un mdls sur les dits rep et/ou fichier...
touch() n'est pas à ma connaissance une fonction C normalisée ou même
répandue, j'ai idée que l'on mélange des choses qui n'ont pas grand'chose à
voir entre elles.
si je crée "à la main" au terminal, une dir (ou un fichier) contenant des caractères Unicode et que je fais un stat dessus (depuis C en castant le path en (char *) ça me dit que le fichier n'existe pas.
Essaye opendir() and co., ou fnmatch(), pour obtenir le «vrai» nom du fichier.
j'imagine comme en entrée du stat c'est un char * qui est demandé, que les routines de comparaisons de string internes n'utilisent pas les wchar_t comme wcscmp ???
stat(2) est un appel système (parfois enrobé dans une très fine couche), donc les routines internes en question sont celles du noyau. Qui n'ont que peu de chances d'être wcscmp(3).
y aurait'il une lib de "wstat" (stat en wchar_t) ???
Peut-être sur ta bécane. Chez moi, non (OS=Minix). Ici, oui (OS=NT; s'appelle _wstat(), de fait).
ce que je trouve curieux est que le mkdir marche, le touch aussi avec des caractères Unicode, mais pas le stat, j'en ai eu la confirmation par un mdls sur les dits rep et/ou fichier...
touch() n'est pas à ma connaissance une fonction C normalisée ou même répandue, j'ai idée que l'on mélange des choses qui n'ont pas grand'chose à voir entre elles.
Antoine
Antoine Leca
<HS> In news:C2E7A137.B00C5%, Eric Levenez va escriure:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Pour continuer dans la catégorie « Usenet fait mal aux drosophiles », FAT-32 en tant que tel n'utilise pas UTF-16, c'est l'extension « VFAT » qui le fait (sur n'importe quel volume FAT, d'ailleurs). La preuve, tu peux monter un volume FAT-32 avec MS-DOS 7.1 ou DR-DOS 7.03+, et les seuls noms de fichiers disponibles seront en page de code «OEM», au format 8.3
Il y avait [y a encore ?] la même subtile distinction pour les options de montage de Linux. Apparement, MacOS X a tout regroupé sous le seul nom de FAT. À raison. </HS>
Antoine
<HS>
In news:C2E7A137.B00C5%news@levenez.com, Eric Levenez va escriure:
Pour créer des accents dans un fichier, par exemple sur une partition
FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la
seule interface disponible sur Mac OS X : l'UTF-8. C'est le système
de fichier FAT de Mac OS X qui va faire la conversion en ce qui va
bien.
Pour continuer dans la catégorie « Usenet fait mal aux drosophiles », FAT-32
en tant que tel n'utilise pas UTF-16, c'est l'extension « VFAT » qui le fait
(sur n'importe quel volume FAT, d'ailleurs).
La preuve, tu peux monter un volume FAT-32 avec MS-DOS 7.1 ou DR-DOS 7.03+,
et les seuls noms de fichiers disponibles seront en page de code «OEM», au
format 8.3
Il y avait [y a encore ?] la même subtile distinction pour les options de
montage de Linux.
Apparement, MacOS X a tout regroupé sous le seul nom de FAT. À raison.
</HS>
<HS> In news:C2E7A137.B00C5%, Eric Levenez va escriure:
Pour créer des accents dans un fichier, par exemple sur une partition FAT-32 (qui utilise de l'UTF-16 en interne), et bien on utilise la seule interface disponible sur Mac OS X : l'UTF-8. C'est le système de fichier FAT de Mac OS X qui va faire la conversion en ce qui va bien.
Pour continuer dans la catégorie « Usenet fait mal aux drosophiles », FAT-32 en tant que tel n'utilise pas UTF-16, c'est l'extension « VFAT » qui le fait (sur n'importe quel volume FAT, d'ailleurs). La preuve, tu peux monter un volume FAT-32 avec MS-DOS 7.1 ou DR-DOS 7.03+, et les seuls noms de fichiers disponibles seront en page de code «OEM», au format 8.3
Il y avait [y a encore ?] la même subtile distinction pour les options de montage de Linux. Apparement, MacOS X a tout regroupé sous le seul nom de FAT. À raison. </HS>
