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.
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire comme le fichier n'existent pas, j'imagine que c'est du à une comparaison interne (???) bien sûr pour passer l'argument du path je suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16 en un encodage ASCII ou autre ?
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom du fichier et donc ne pas utiliser les 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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/08/07 15:08, dans
<1187096928.158626.224350@57g2000hsv.googlegroups.com>, « unbewust »
<yvon.thoraval@gmail.com> a écrit :
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui
a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères
unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire
comme le fichier n'existent pas, j'imagine que c'est du à une
comparaison interne (???) bien sûr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16
en un encodage ASCII ou autre ?
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom
du fichier et donc ne pas utiliser les 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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire comme le fichier n'existent pas, j'imagine que c'est du à une comparaison interne (???) bien sûr pour passer l'argument du path je suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16 en un encodage ASCII ou autre ?
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom du fichier et donc ne pas utiliser les 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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
unbewust
On 14 août, 16:28, Eric Levenez wrote:
Le 14/08/07 15:08, dans , « unbewust »
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire comme le fichier n'existent pas, j'imagine que c'est du à une comparaison interne (???) bien sûr pour passer l'argument du path je suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16 en un encodage ASCII ou autre ?
ah non pas du tout...
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom du fichier et donc ne pas utiliser les wchar_t.
AH, alors là, je ne pige pas, comment ça se débrouille, mais tant mieux, c'est plus simple.
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
On 14 août, 16:28, Eric Levenez <n...@levenez.com> wrote:
Le 14/08/07 15:08, dans
<1187096928.158626.224...@57g2000hsv.googlegroups.com>, « unbewust »
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui
a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères
unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire
comme le fichier n'existent pas, j'imagine que c'est du à une
comparaison interne (???) bien sûr pour passer l'argument du path je
suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir
wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16
en un encodage ASCII ou autre ?
ah non pas du tout...
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom
du fichier et donc ne pas utiliser les wchar_t.
AH, alors là, je ne pige pas, comment ça se débrouille, mais tant
mieux, c'est plus simple.
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...
si je crée un dossier avec des caractères Unicode :
$> mkdir été
ou :
$> touch été.txt
si je fais un mdls là-dessus, pas de pb, j'imagine que c'est Apple qui a conçu le mdls (?)
le mdls confirme que touch et mkdir "passent" avec des caractères unicode
mdls affiche d'ailleurs de deux maniers ce path :
été ou "e' te' "
par contre si je fais un stat dessus, stat trouve que le répertoire comme le fichier n'existent pas, j'imagine que c'est du à une comparaison interne (???) bien sûr pour passer l'argument du path je suis obliger, avec stat de faire un cast (char *) (au lieu d'avoir wchar_t)
Et tu crois qu'un cast d'un pointeur va changer un encodage Unicode UTF-16 en un encodage ASCII ou autre ?
ah non pas du tout...
Comme répondu dans fclc il faut que tu utilises l'UTF-8 pour encoder le nom du fichier et donc ne pas utiliser les wchar_t.
AH, alors là, je ne pige pas, comment ça se débrouille, mais tant mieux, c'est plus simple.
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
Eric Levenez
Le 14/08/07 17:35, dans , « unbewust » a écrit :
On 14 août, 16:28, Eric Levenez wrote:
Le 14/08/07 15:08, dans , « unbewust »
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être encodé de plusieurs manières (type et ordre des caractères d'échappement). Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pour qu'un caractère soit toujours codé de la même manière), et c'est seulement après que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ainsi quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open est normalisée et comparé à l'UTF-16 interne déjà normalisé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/08/07 17:35, dans
<1187105705.626887.272250@l70g2000hse.googlegroups.com>, « unbewust »
<yvon.thoraval@gmail.com> a écrit :
On 14 août, 16:28, Eric Levenez <n...@levenez.com> wrote:
Le 14/08/07 15:08, dans
<1187096928.158626.224...@57g2000hsv.googlegroups.com>, « unbewust »
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être
encodé de plusieurs manières (type et ordre des caractères d'échappement).
Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pour qu'un
caractère soit toujours codé de la même manière), et c'est seulement après
que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler
qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ainsi
quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open
est normalisée et comparé à l'UTF-16 interne déjà normalisé.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être encodé de plusieurs manières (type et ordre des caractères d'échappement). Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pour qu'un caractère soit toujours codé de la même manière), et c'est seulement après que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ainsi quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open est normalisée et comparé à l'UTF-16 interne déjà normalisé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
unbewust
On 14 août, 18:23, Eric Levenez wrote:
Le 14/08/07 17:35, dans , « unbewust »
On 14 août, 16:28, Eric Levenez wrote:
Le 14/08/07 15:08, dans , « unbewust »
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être encodé de plusieurs manières (type et ordre des caractères d'écha ppement). Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pou r qu'un caractère soit toujours codé de la même manière), et c'est seulem ent après que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ain si quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open est normalisée et comparé à l'UTF-16 interne déjà normalisé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
oui, oui, je suis d'accord, je pense que la norme unix en ce qui concerne l'encodage (d'après ce que j'ai lu) est UTF-8 et évite effectivement certains pbs liés au codages multiple d'autant qu'aucun multi-byte ne peut commence par un "0" (fin de chaine en C)
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très bien avec ça en tout cas.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement représenté,
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
mais ce n'est peut-être pas le même pb...
A+
Yvon
On 14 août, 18:23, Eric Levenez <n...@levenez.com> wrote:
Le 14/08/07 17:35, dans
<1187105705.626887.272...@l70g2000hse.googlegroups.com>, « unbewust »
On 14 août, 16:28, Eric Levenez <n...@levenez.com> wrote:
Le 14/08/07 15:08, dans
<1187096928.158626.224...@57g2000hsv.googlegroups.com>, « unbewust »
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions
traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les
comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être
encodé de plusieurs manières (type et ordre des caractères d'écha ppement).
Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pou r qu'un
caractère soit toujours codé de la même manière), et c'est seulem ent après
que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler
qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ain si
quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open
est normalisée et comparé à l'UTF-16 interne déjà normalisé.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
oui, oui, je suis d'accord, je pense que la norme unix en ce qui
concerne l'encodage (d'après ce que j'ai lu) est UTF-8 et évite
effectivement certains pbs liés au codages multiple d'autant qu'aucun
multi-byte ne peut commence par un "0" (fin de chaine en C)
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant
plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais
dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très
bien avec ça en tout cas.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement
représenté,
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...
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.
Mauvais questions :-) Il suffit d'utiliser toutes les fonctions traditionnelles mais en utilisant l'UTF-8.
tant mieux mais le seul truc que je ne vois pas c'est comment les comparaisons se font...
Là c'est plus compliqué. En effet en UTF-8 un même caractère peut être encodé de plusieurs manières (type et ordre des caractères d'écha ppement). Pour comparer 2 chaînes Unicode Mac OS X normalise les 2 chaînes (pou r qu'un caractère soit toujours codé de la même manière), et c'est seulem ent après que la comparaison est faite.
<http://en.wikipedia.org/wiki/Unicode_normalization>. Je crois me rappeler qu'Apple utilise le NFD.
Le système de fichier HFS+ de Mac OS X utilise en interne l'UTF-16. Ain si quand on demande d'ouvrir le ficher "éric.txt", l'UTF-8 de la chaîne du open est normalisée et comparé à l'UTF-16 interne déjà normalisé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
oui, oui, je suis d'accord, je pense que la norme unix en ce qui concerne l'encodage (d'après ce que j'ai lu) est UTF-8 et évite effectivement certains pbs liés au codages multiple d'autant qu'aucun multi-byte ne peut commence par un "0" (fin de chaine en C)
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très bien avec ça en tout cas.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement représenté,
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
mais ce n'est peut-être pas le même pb...
A+
Yvon
Eric Levenez
Le 14/08/07 18:32, dans , « unbewust » a écrit :
oui, oui, je suis d'accord, je pense que la norme unix en ce qui concerne l'encodage (d'après ce que j'ai lu) est UTF-8
Je ne pense pas. Lors de la certification Unix (passée par Leopard), le fournisseur donne liste des encodage qu'il utilise. Je ne pense pas que quoi que ce soit ne soit imposé.
et évite effectivement certains pbs liés au codages multiple d'autant qu'aucun multi-byte ne peut commence par un "0" (fin de chaine en C)
L'UTF-8 est très bien pour sa compatibilité mais pose énormément de problèmes pour les séquences mal formées, qui, si elles ne sont pas bien traitées, peuvent entraîner des plantages applicatifs, et donc des trous de sécurité. Apple a corrigé depuis la sortie de Mac OS X 10.0 beaucoup de problèmes là dessus.
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très bien avec ça en tout cas.
mdls est bien sûr l'oeuvre d'Apple car cette commande repose sur les technologies Apple.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement représenté,
Mais si, aucun problème avec Terminal. Aucune idée avec iTerm.
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/08/07 18:32, dans
<1187109153.836334.134820@b79g2000hse.googlegroups.com>, « unbewust »
<yvon.thoraval@gmail.com> a écrit :
oui, oui, je suis d'accord, je pense que la norme unix en ce qui
concerne l'encodage (d'après ce que j'ai lu) est UTF-8
Je ne pense pas. Lors de la certification Unix (passée par Leopard), le
fournisseur donne liste des encodage qu'il utilise. Je ne pense pas que quoi
que ce soit ne soit imposé.
et évite
effectivement certains pbs liés au codages multiple d'autant qu'aucun
multi-byte ne peut commence par un "0" (fin de chaine en C)
L'UTF-8 est très bien pour sa compatibilité mais pose énormément de
problèmes pour les séquences mal formées, qui, si elles ne sont pas bien
traitées, peuvent entraîner des plantages applicatifs, et donc des trous de
sécurité. Apple a corrigé depuis la sortie de Mac OS X 10.0 beaucoup de
problèmes là dessus.
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant
plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais
dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très
bien avec ça en tout cas.
mdls est bien sûr l'oeuvre d'Apple car cette commande repose sur les
technologies Apple.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement
représenté,
Mais si, aucun problème avec Terminal. Aucune idée avec iTerm.
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
oui, oui, je suis d'accord, je pense que la norme unix en ce qui concerne l'encodage (d'après ce que j'ai lu) est UTF-8
Je ne pense pas. Lors de la certification Unix (passée par Leopard), le fournisseur donne liste des encodage qu'il utilise. Je ne pense pas que quoi que ce soit ne soit imposé.
et évite effectivement certains pbs liés au codages multiple d'autant qu'aucun multi-byte ne peut commence par un "0" (fin de chaine en C)
L'UTF-8 est très bien pour sa compatibilité mais pose énormément de problèmes pour les séquences mal formées, qui, si elles ne sont pas bien traitées, peuvent entraîner des plantages applicatifs, et donc des trous de sécurité. Apple a corrigé depuis la sortie de Mac OS X 10.0 beaucoup de problèmes là dessus.
donc oui, ça doit pouvoir se faire, je vais vérifier ça en n'utilisant plus les wchar_t et regarder si stat (plutôt lstat d'ailleurs) mais dit oui ou non que mon fichier "été.txt" existe bien...
mdls (sans doute une fonction écrite par Apple) se débriouille très bien avec ça en tout cas.
mdls est bien sûr l'oeuvre d'Apple car cette commande repose sur les technologies Apple.
mais déjà sur Terminal comme sur iTerm l'UTF-8 n'est pas correctement représenté,
Mais si, aucun problème avec Terminal. Aucune idée avec iTerm.
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2E7AB56.B00E5%, Eric Levenez écrit:
Le 14/08/07 18:32, dans , « unbewust » a écrit : [...]
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils) qu'une option (-w) posant des problèmes de sécurité.
Dans l'article <C2E7AB56.B00E5%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 14/08/07 18:32, dans
<1187109153.836334.134820@b79g2000hse.googlegroups.com>, « unbewust »
<yvon.thoraval@gmail.com> a écrit :
[...]
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt"
quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.
Dans l'article <C2E7AB56.B00E5%, Eric Levenez écrit:
Le 14/08/07 18:32, dans , « unbewust » a écrit : [...]
dans terminal j'ai "e??te??.txt" et dans iTerm j'ai "e##te##.txt" quand je fais un ls -al sur le rep en question...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls -wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
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 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é, l'option -w est voulue. 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.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 15/08/07 4:03, dans <20070815020216$30c8@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> 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é, l'option -w est voulue. 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.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
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é, l'option -w est voulue. 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.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <20070815020216$, Vincent Lefevre <vincent+ wrote:
qu'une option (-w) posant des problèmes de sécurité.
C'est à dire ?
Patrick -- Patrick Stadelmann
In article <20070815020216$30c8@prunille.vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> wrote:
qu'une option (-w) posant des problèmes de sécurité.
C'est à dire ?
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <20070815020216$, Vincent Lefevre <vincent+ wrote:
qu'une option (-w) posant des problèmes de sécurité.
C'est à dire ?
Patrick -- Patrick Stadelmann
unbewust
On 14 août, 18:56, Eric Levenez wrote:
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls - wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
OK, c'est bon, en fait lstat marche trè bien sur de l'UTF-8 pourvu qu'on ne passe pas en wchar_t...
merci, A+
Yvon
On 14 août, 18:56, Eric Levenez <n...@levenez.com> wrote:
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls - wal"
pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi
laisser l'encodage de Terminal en UTF-8 bien sûr.
OK, c'est bon, en fait lstat marche trè bien sur de l'UTF-8 pourvu
qu'on ne passe pas en wchar_t...
Un petit "man ls" t'aurait expliqué le problème : il faut faire "ls - wal" pour que "ls" n'interprète pas les caractères non ASCII. Il faut aussi laisser l'encodage de Terminal en UTF-8 bien sûr.
OK, c'est bon, en fait lstat marche trè bien sur de l'UTF-8 pourvu qu'on ne passe pas en wchar_t...
merci, A+
Yvon
unbewust
On 15 août, 04:03, Vincent Lefevre <vincent+ wrote:
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils) qu'une option (-w) posant des problèmes de sécurité.
c'est lequel celui-là ???
car je viens de m'apercevoir que le ls que j'utilise ne correspond pas à celui du man...
sans doute le MAN_PATh n'est pas dans le même ordre que le PATH...
On 15 août, 04:03, Vincent Lefevre <vincent+n...@vinc17.org> wrote:
Il vaut mieux utiliser un ls non buggé (e.g. celui des coreutils)
qu'une option (-w) posant des problèmes de sécurité.
c'est lequel celui-là ???
car je viens de m'apercevoir que le ls que j'utilise ne correspond pas
à celui du man...
sans doute le MAN_PATh n'est pas dans le même ordre que le PATH...
