Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Matériel Ordinateur Mac Programmation path en Unicode et stat...

path en Unicode et stat...

30 réponses
Avatar
unbewust
si je cr=E9e un dossier avec des caract=E8res Unicode :

$> mkdir =E9t=E9

ou :

$> touch =E9t=E9.txt

si je fais un mdls l=E0-dessus, pas de pb, j'imagine que c'est Apple qui
a con=E7u le mdls (?)


le mdls confirme que touch et mkdir "passent" avec des caract=E8res
unicode

mdls affiche d'ailleurs de deux maniers ce path :

=E9t=E9 ou "e' te' "

par contre si je fais un stat dessus, stat trouve que le r=E9pertoire
comme le fichier n'existent pas, j'imagine que c'est du =E0 une
comparaison interne (???) bien s=FBr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)


donc ma question, est-ce qu'il existe des fonctions telles que stat
and Co en wchar_t ??? comme il existe des fonctions pour les strings
en multi-bytes.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Vincent Lefevre
Dans l'article <C2E86DA8.B01AB%,
Eric Levenez écrit:

Le 15/08/07 4:03, dans <20070815020216$, « Vincent
Lefevre » <vincent+ a écrit :

Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.


Le "ls" de Mac OS X n'est pas buggé,


Si, il ne se comporte pas correctement, à savoir, respecter les locales.

l'option -w est voulue.


Non, on ne devrait pas en avoir besoin.

Et le problème de sécurité sur l'exécution de code est vraiment
limite et existe sur tout les ls en mode raw.


Justement, faut pas utiliser le mode raw. Donc pas d'option -w.

Par exemple, dans un répertoire où il y a deux fichiers "anb" et "é":

prunille:~/blah> /bin/ls -l
total 0
-rw-r--r-- 1 vinc17 vinc17 0 Aug 16 06:16 a?b
-rw-r--r-- 1 vinc17 vinc17 0 May 20 23:19 e??
prunille:~/blah> /bin/ls -lw
total 0
-rw-r--r-- 1 vinc17 vinc17 0 Aug 16 06:16 a
b
-rw-r--r-- 1 vinc17 vinc17 0 May 20 23:19 é

On voit qu'avec l'option -w, le ls de Mac OS X interprète les
caractères de contrôle (c'est le mode raw), et le problème est
que les séquences d'échappement peuvent reconfigurer le terminal
ou envoyer son contenu à l'imprimante!

Mais avec le ls des coreutils:

prunille:~/blah> /usr/local/bin/ls -l
total 0
-rw-r--r-- 1 vinc17 vinc17 0 2007-08-16 06:16:10 a?b
-rw-r--r-- 1 vinc17 vinc17 0 2007-05-20 23:19:41 é

on voit qu'il n'y a pas besoin du mode raw. Il tient compte des
locales et c'est suffisant.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Vincent Lefevre
Dans l'article ,
Patrick Stadelmann écrit:

In article <20070815020216$,
Vincent Lefevre <vincent+ wrote:

qu'une option (-w) posant des problèmes de sécurité.


C'est à dire ?


Elle envoie tous les caractères au terminal, y compris les caractères
non imprimables (séquences d'échappement, etc.). Cf l'autre post que
je viens de faire.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Vincent Lefevre
Dans l'article <20070816042418$,
Vincent Lefevre <vincent+ écrit:

Dans l'article ,
Patrick Stadelmann écrit:

In article <20070815020216$,
Vincent Lefevre <vincent+ wrote:

qu'une option (-w) posant des problèmes de sécurité.


C'est à dire ?


Elle envoie tous les caractères au terminal, y compris les caractères
non imprimables (séquences d'échappement, etc.). Cf l'autre post que
je viens de faire.


D'ailleurs, si tu veux un petit exemple, tu peux taper:

$ touch `printf 'e[?40;3h'`
$ /bin/ls -w

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



Avatar
Eric Levenez
Le 16/08/07 6:24, dans <20070816040944$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C2E86DA8.B01AB%,
Eric Levenez écrit:

Le 15/08/07 4:03, dans <20070815020216$, « Vincent
Lefevre » <vincent+ a écrit :

Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.


Le "ls" de Mac OS X n'est pas buggé,


Si, il ne se comporte pas correctement, à savoir, respecter les locales.


C'est un choix d'Apple délibéré.

l'option -w est voulue.


Non, on ne devrait pas en avoir besoin.

Et le problème de sécurité sur l'exécution de code est vraiment
limite et existe sur tout les ls en mode raw.


Justement, faut pas utiliser le mode raw. Donc pas d'option -w.

Par exemple, dans un répertoire où il y a deux fichiers "anb" et "é":

prunille:~/blah> /bin/ls -l
total 0
-rw-r--r-- 1 vinc17 vinc17 0 Aug 16 06:16 a?b
-rw-r--r-- 1 vinc17 vinc17 0 May 20 23:19 e??
prunille:~/blah> /bin/ls -lw
total 0
-rw-r--r-- 1 vinc17 vinc17 0 Aug 16 06:16 a
b
-rw-r--r-- 1 vinc17 vinc17 0 May 20 23:19 é

On voit qu'avec l'option -w, le ls de Mac OS X interprète les
caractères de contrôle (c'est le mode raw), et le problème est
que les séquences d'échappement peuvent reconfigurer le terminal
ou envoyer son contenu à l'imprimante!


Ceci n'est pas lié à "ls" mais est lié à l'émulateur de Terminal et cela est
vrai pour tout ce qui est affiché à l'écran. Un simple "cat" peut avoir le
problème que tu décris et ceci sur tout système.

Mais avec le ls des coreutils:

prunille:~/blah> /usr/local/bin/ls -l
total 0
-rw-r--r-- 1 vinc17 vinc17 0 2007-08-16 06:16:10 a?b
-rw-r--r-- 1 vinc17 vinc17 0 2007-05-20 23:19:41 é

on voit qu'il n'y a pas besoin du mode raw. Il tient compte des
locales et c'est suffisant.


"Suffisant" pour qui ? Ne plus afficher correctement les caractères d'un nom
est pour moi un bug.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.



Avatar
Vincent Lefevre
Dans l'article <C2E9C6B9.B02DA%,
Eric Levenez écrit:

Ceci n'est pas lié à "ls" mais est lié à l'émulateur de Terminal et
cela est vrai pour tout ce qui est affiché à l'écran.


C'est bien lié à ls dans la mesure où ls doit faire un filtrage
lorsque la sortie se fait sur un terminal (comme avec la plupart
des programmes), surtout que l'utilisateur ne contrôle pas toujours
les noms de fichiers.

Un simple "cat" peut avoir le problème que tu décris et ceci sur
tout système.


Oui, mais c'est volontaire, car un fichier peut contenir des données
formatées pour le terminal. Mais en général, l'utilisateur n'est pas
censé utilisé cat avec sortie sur le terminal (sauf cas particulier),
mais des outils comme less ou des éditeurs de texte.

Mais avec le ls des coreutils:

prunille:~/blah> /usr/local/bin/ls -l
total 0
-rw-r--r-- 1 vinc17 vinc17 0 2007-08-16 06:16:10 a?b
-rw-r--r-- 1 vinc17 vinc17 0 2007-05-20 23:19:41 é

on voit qu'il n'y a pas besoin du mode raw. Il tient compte des
locales et c'est suffisant.


"Suffisant" pour qui ? Ne plus afficher correctement les caractères
d'un nom est pour moi un bug.


Par définition, un caractère non affichable ne peut pas être affiché
correctement. Par exemple:

$ touch `printf 'abz'`
$ /bin/ls
a?z
$ /bin/ls -w
z

Ça t'avance à quoi d'obtenir 'z', qui n'est même pas le nom du fichier?
Le mieux reste l'option -b du ls des coreutils (que j'utilise d'ailleurs
par défaut via un alias), qui remplace les caractères non affichables
par des séquences telles qu'on les écrit en C:

$ /usr/local/bin/ls -b
abz

Ainsi on ne perd aucune information, contrairement aux autres solutions,
et ça reste entièrement lisible et réutilisable par copy-paste.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Eric Levenez
Le 16/08/07 15:09, dans <20070816124846$, « Vincent
Lefevre » <vincent+ a écrit :

[snip]


Tu préfères le ls du GNU, je préfère celui de BSD. Chacun son truc.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
Vincent Lefevre
Dans l'article <C2EA28A2.B033B%,
Eric Levenez écrit:

Le 16/08/07 15:09, dans <20070816124846$, « Vincent
Lefevre » <vincent+ a écrit :

[snip]


Tu préfères le ls du GNU, je préfère celui de BSD. Chacun son truc.


Ben oui, je préfère un ls compatible POSIX, ce que n'est pas le
ls de BSD. Quelles que soient les options, ls doit afficher les
caractères imprimables, et POSIX dit à ce propos:

LC_CTYPE
Determine the locale for the interpretation of sequences of bytes
of text data as characters (for example, single-byte as opposed
to multi-byte characters in arguments) and which characters are
defined as printable (character class print).

Le fait que le ls de BSD n'en tienne pas compte est un bug. En fait,
c'est peut-être un problème dû aux combining characters (puisque NFD
est utilisée), auquel cas le bug a déjà été rapporté pour FreeBSD:

http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/109367

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Avatar
Eric Levenez
Le 17/08/07 4:32, dans <20070817021808$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C2EA28A2.B033B%,
Eric Levenez écrit:

Le 16/08/07 15:09, dans <20070816124846$, « Vincent
Lefevre » <vincent+ a écrit :

[snip]


Tu préfères le ls du GNU, je préfère celui de BSD. Chacun son truc.


Ben oui, je préfère un ls compatible POSIX, ce que n'est pas le
ls de BSD.


Je préfère l'impémentation Apple du système où tout est en UTF-8 plutôt que
celle des autres BSD ou de Linux où des conversions dans tous les sens sont
ou devraient être fait. Chacun son truc je le répète, je préfère voir les
caractères des fichiers tels qu'ils sont. Par défaut les caractères spéciaux
ne sont pas affichés. La norme Posix n'impose pas d'avoir plusieurs locales
et donc les defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour
la compatibilité Posix, merci de repasser :-)

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.



Avatar
Vincent Lefevre
Dans l'article <C2EB2414.B045B%,
Eric Levenez écrit:

Je préfère l'impémentation Apple du système où tout est en UTF-8


HFS+ est en UTF-8. Pour le reste, tout dépend des locales. Et un
"touch é" ne fonctionne correctement qu'avec des locales UTF-8.

plutôt que celle des autres BSD ou de Linux où des conversions dans
tous les sens sont ou devraient être fait. Chacun son truc je le
répète, je préfère voir les caractères des fichiers tels qu'ils
sont.


Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.

Par défaut les caractères spéciaux ne sont pas affichés.


Un 'é' n'est pas un caractère spécial. Et si ça en était un, ls
devrait afficher un '?' (par exemple) à la place. Mais à la place,
il envoie sur le terminal n'importe quoi, y compris des séquences
non UTF-8! Il n'y a qu'à voir la conversion faite par /bin/ls: sur
un répertoire contenant un 'é' et un symbole euro,
_ "/bin/ls -w | hexdump -C" donne "65 cc 81 0a e2 82 ac 0a"
_ "/bin/ls -q | hexdump -C" donne "65 cc 3f 0a e2 3f ac 0a"

Faire une transformation des bytes 80..9f en 3f alors que les noms
de fichier sont en UTF-8, c'est n'importe quoi.

La norme Posix n'impose pas d'avoir plusieurs locales et donc les
defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la
compatibilité Posix, merci de repasser :-)


Les locales sont définies par le système. Dans la mesure où Apple
supporte UTF-8, et que c'est même la locale du système de fichiers
HFS+, ls /bin/ls doit la supporter.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Avatar
Eric Levenez
Le 17/08/07 15:07, dans <20070817125547$, « Vincent
Lefevre » <vincent+ a écrit :

Dans l'article <C2EB2414.B045B%,
Eric Levenez écrit:

Je préfère l'impémentation Apple du système où tout est en UTF-8


HFS+ est en UTF-8.


Il est en UTF-16.

Pour le reste, tout dépend des locales. Et un
"touch é" ne fonctionne correctement qu'avec des locales UTF-8.


UTF-8 est ce qu'il faut utiliser partout dans Mac OS X, oui.

plutôt que celle des autres BSD ou de Linux où des conversions dans
tous les sens sont ou devraient être fait. Chacun son truc je le
répète, je préfère voir les caractères des fichiers tels qu'ils
sont.


Justement, tu ne les vois pas tels qu'ils sont avec le /bin/ls.


Avec ton ls du GNU qui lui aussi masque certains caractères.

La norme Posix n'impose pas d'avoir plusieurs locales et donc les
defines type LC_CTYPE peuvent ne pas avoir d'effet. Alors pour la
compatibilité Posix, merci de repasser :-)


Les locales sont définies par le système. Dans la mesure où Apple
supporte UTF-8, et que c'est même la locale du système de fichiers
HFS+, ls /bin/ls doit la supporter.


Il n'y a aucun problème à part ceux que tu te poses toi-même. Le ls de base
marche bien et ne perturbe pas l'écran. Avec l'option qui va bien on voit
tous les codes UTF-8 des noms des fichiers. Aucun soucis. Je sais tu tu n'es
pas d'accord.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


1 2 3