Linux? - Page 103

en 2012, ne pas savoir gérer les accents dans les noms de fichiers, c'est quand même franchement la loose…

D'ailleurs, petit test amusant :

python -c "from unicodedata import normalize as n; open(n('NFKD', u'é'), 'w').write('toto'); open(n('NFKC', u'é'), 'w').write('tatatata')"
ls -l

Et magie, vous avez deux fichiers différents avec le même nom !

linus te dira que c'est inutile, assorti de différents arguments techniques probablement valables.

squalyl (./3063) :
linus te dira que c'est inutile, assorti de différents arguments techniques probablement valables.

Oui, c'est vrai, ne pas pouvoir retrouver un fichier à partir de son nom, ça ne sert à rien, un peu comme pouvoir garantir l'unicité des noms de fichiers.

il faudra attendre qu'il le subisse, puis dans une conférence il fera un gros doigt "fuck you unicode" et là les autres ils auront les chocottes et ils règleront leur merde

Le problème vient de Linux, pas d'Unicode (même si Unicode est *très* loin d'être parfait). Windows et OS X arrivent très bien à gérer les noms accentués.

donc en gros on peut normaliser de plusieurs manières qui s'affichent pareil, et linux ne renormalise pas selon la méthode officielle?

Voilà ^^
Linux ne fait *rien*. Tu pourrais lui refourguer un nom de fichier latin-1 ou utf-32, il s'en fout. Simplement, il s'attend à ce que tu lui fournisses de l'UTF-8.

Manque de pot, l'UTF-8 spécifie plusieurs manières de normaliser, et pour le coup, rien n'est dit sur la normalisation attendue.


Quant aux autres OS, ils te garantissent au moins que quelque soit ta façon de normaliser, ça sera le même fichier. Par exemple, avec ma ligne de Python, je n'ai bien qu'un seul fichier sur OS X.

voila c'est l'argument fallacieux auquel je pensais, les noms de fichiers sont des chaines C, sans avoir à se faire chier avec de l'unicode, open() prend un char* et puis c'est tout.

et c'est probablement dit par posix, en plus, non?

ce serait ptet à la libc de faire quelque chose, soit dans le fopen normal si posix l'autorise, soit dans une fonction à la noix non posix ^^

mais vu le caractère de son mainteneur ...

Date: 1991-10-05 08:53:28 PST
I can (well, almost) hear you asking yourselves "why?". Hurd will be
out in a year (or two, or next month, who knows), and I've already got
minix. This is a program for hackers by a hacker.

Dans ce cas, c'est complètement débile, ça veut dire que tu peux utiliser n'importe quel encodage, et que l'application n'a aucun moyen de savoir quel encodage a été utilisé...

bah oui en effet

mais de là à y faire quelque chose...

D'un autre côté, le problème à la racine semble quand même être unicode, l'implémentation de la libc ou du noyau serait probablement correcte si unicode était plus propre qu'actuellement. En tout cas, moi j'ai pas de souci d'accents, j'en mets pas. Je suis un vrai geek. #killer_argument#

justement, au lieu de mal supporter les fichiers unicode, ils feraient mieux de les refuser (ou même de convertir manumilitari en ascii les noms de fichiers)

Oui mais ce serait pas une méthode STANDARD §§§§

Ben à unicode de proposer un vrai standard.

Folco (./3073) :
D'un autre côté, le problème à la racine semble quand même être unicode, l'implémentation de la libc ou du noyau serait probablement correcte si unicode était plus propre qu'actuellement. En tout cas, moi j'ai pas de souci d'accents, j'en mets pas. Je suis un vrai geek. #killer_argument#

Oui, bien sûr, s'il n'y avait pas de problème, il serait plus facile à régler.

Sauf que :
* d'une part, ce n'est pas en faisant comme s'il n'existait pas qu'il va disparaître,
* d'autre part, il pourrait forcer au moins l'encodage (ce qui n'est même pas le cas),
* les autres OS y arrivent très bien.

il leur suffirait de dire : c'est TEL encodage et si c'est pas le cas, on force.

Je pense qu'ils ont déjà dû avoir cette discussion en interne… Et qu'un ayatollah du standard a menacé de retenir sa respiration si jamais on s'en écartait.

Voilà, exactement ça

Sauf qu'il y a toutes les chances pour qu'il y ait d'autres (bonnes) raisons derrière, à moins que dévelopeur open source == abruti pour toi. Je te conseille de postuler chez Disney.

a mon avis le choix de char* ou wchar_t* pour les chaines est une décision à prendre à la base. Imagine si ils doivent faire ce changement partout dans le noyau où des chaines sont utilisées

Ouep, ça doit sûrement rentrer en ligne de compte. Le boulot est monumental derrière.

Folco (./3082) :
Sauf qu'il y a toutes les chances pour qu'il y ait d'autres (bonnes) raisons derrière, à moins que dévelopeur open source == abruti pour toi. Je te conseille de postuler chez Disney.

Parfois, oui…

Par exemple, j'ai réinstallé mon Windows 7 et comme il fallait s'y attendre, le système a (mal) réécrit le secteur de boot et a rendu mon Ubuntu 11.04 inaccessible.

Solution : lancer boot-repair. Sauf que le gus qui avait codé ça n'a mis ce paquet à disposition que pour les versions LTS
Et au lieu d'installer un bête paquet de 2 Mo, je me suis retrouvé à télécharger un ISO de 320 Mo, à aller ensuite dans un Leclerc pour acheter des CD vierges, faute de clé USB disponible, et ENFIN graver le CD. Grosse perte de temps qui aurait pu être évitée si les binaires étaient seulement disponibles avec ma version d'Ubuntu

faut pas déconner non plus.

squalyl (./3083) :
a mon avis le choix de char* ou wchar_t* pour les chaines est une décision à prendre à la base. Imagine si ils doivent faire ce changement partout dans le noyau où des chaines sont utilisées

Les autres OS y arrivent très bien, pourtant. Et c'est un truc qui aurait pu être pris en compte dès le début ; que je sache, les accents existaient déjà en 1991

YN -> je comprends que ça t'aies fait super chier, mais c'est quand même pas de la faute de Ubuntu, de Linux ou du Filesystem si tel ou tel programme n'est pas packagé pour ta distro. Du temps de MSDOS/Win<98, on avait toujours une disquette de boot sous la main (tu sais, "format /s a:"). Maintenant, c'est un liveCD ou un clé USB formatée comme il faut, c'est comme ça.

Comme déjà dit, l'encodage est le boulot de l'userspace, pas du noyau. La convention dit que le nom du fichier est censé être en NFC (plus précisément: que le nom des fichiers dans un locale UTF-8 est censé être en UTF-8 NFC – si tu utilises un des locales préhistoriques non-UTF-8, alors l'encodage des noms de fichiers est celui du locale), si tu utilises autre chose, PEBKAC.

flanker (./3068) :
Quant aux autres OS, ils te garantissent au moins que quelque soit ta façon de normaliser, ça sera le même fichier. Par exemple, avec ma ligne de Python, je n'ai bien qu'un seul fichier sur OS X.

Et ce n'est pas normal. Tu as utilisé 2 noms différents, ce sont 2 fichiers différents. Le noyau n'a pas à normaliser quoi que ce soit. Ce serait d'ailleurs impossible sous GNU/Linux parce qu'un nom de fichier du noyau Linux est une séquence d'octets, rien ne dit que c'est de l'UTF-8. (D'ailleurs, si tu utilises par exemple un locale Latin1, les noms de fichiers seront normalement en Latin1, du moins si tes applications fonctionnent correctement. Mais les locales non-UTF-8 sont dépréciés.)

flanker (./3071) :
Dans ce cas, c'est complètement débile, ça veut dire que tu peux utiliser n'importe quel encodage, et que l'application n'a aucun moyen de savoir quel encodage a été utilisé...

L'encodage est censé être celui du locale (et pour l'UTF-8, en NFC), si l'application qui écrit le fichier ne respecte pas ça, ce n'est pas la faute de celle qui le lit si elle ne le trouve pas.

squalyl (./3083) :
a mon avis le choix de char* ou wchar_t* pour les chaines est une décision à prendre à la base. Imagine si ils doivent faire ce changement partout dans le noyau où des chaines sont utilisées

C'est pourri, les wchar; l'UTF-8 est la bonne solution (compatible ASCII, ne gaspille pas de place si on ne met que de l'ASCII, et les mêmes routines peuvent être utilisées pour l'UTF-8 et pour tous les encodages obsolètes en 8 bits, sans devoir passer par des conversions potentiellement à perte).

flanker (./3087) :
Et c'est un truc qui aurait pu être pris en compte dès le début ; que je sache, les accents existaient déjà en 1991

Mais pas l'Unicode! Il y avait plein d'encodages différents selon le locale, et donc la solution la plus simple et la plus logique a été retenue: on accepte une séquence d'octets quelconque et c'est à l'userspace d'utiliser le bon locale.