Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr).
Le contenu des fichiers, on s'en fout. Si le programme qui est supposé ouvrir un fichier ne gère pas UTF-8, ben soit on ouvre avec un autre programme, soit on prend sur soi et on code un pacth. Sinon recode marche du feu de dieu dans la plupart des cas.
Par contre le shell lui c'est une autre paire de manche. Si le shell est en UTF-8, ca veut dire que tout un tas d'autres trucs doivent être en UTF-8, la locale le LANG moult parmètres pour less, perl, python, ruby etc. Sinon il va se passer de drôles de trucs à l'execution de certains scripts.
Mais bon ca c'est encore gérable.
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier - Aucun meta ne permet de le savoir, du moins pas sur les filesystems classiques. A partir de là pour pouvoir utiliser des programmes aussi courants que tar, git-clone, unzip, perl, python etc. il faut :
- soit se mettre d'accord avec le monde entier pour que tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
- Soit utiliser exclusivement les caractères ANSI dans tous les scripts/archives/backups/repo/sources etc.
Sinon tu prends le risques réel que ton programme fasse n'importe quoi. Supposons que ton make clean fasse un rm -r sur /home/toi/┌/obj et que ton parseur bute sur le ┌ qu'il interprete comme une terminaison (Je sais ca ne peux pas être le cas avec ce caractère là, c'est même pour ça que je l'ai choisi). Il va se passer quoi à ton avis ? Déjà ton make clean ne finira pas, et ensuite tu vas avoir plein de place libre sur ton ~….
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Autre problème, mosh utilise SSH pour se connecter à la machine distante. Sauf que en SSH il faut déclarer le type de terminal et également remaper un certain nombre de combinaisons de touches. A partir de là soit toute la chaine (emulateur terminal, serveur ssh, shell) est en UTF-8, soit je suis curieux de savoir ce qui va se passer quand je vais faire ctrl+H.
mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite)
Ce n'est pas très grave pour la discussion en cours, mais ce n'est pas moi que tu vas citer.
parce que la led num lock ne s'allume pas dans certains cas en console,
Il ne s'agit pas de la led numlock, mais de la led capslock. Ou pour être exact à cause du local echo les caractères vont s'afficher en local comme si il s'agissait d'un caps lock mais être interpretés par mosh en bout de chaine comme si il s'agissait d'un shiftlock.
Par exemple si je tape 88 via le pavée numérique en capslock chez moi, je verais s'afficher 88 sur mon emulateur terminal, mais le shell recevra deux fois l'instruction "commande précédente". Ca peut faire des trucs très drôle. Par exemple tu penses avoir lancé un worker tomcat sur le port 8088 ? Perdu tu as réexecuté la commande 3 slots plus haut et tu es passé en mode insertion.
t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
Non, quand on veut tuer UTF-8 on le présente comme la solution absolue à tous les problèmes dans tous les cas et sur toutes les machines. Alors bien sur il y a des gens qui vont y croire, mais au bout du 15ème incident incompréhensible ils vont gentillement repasser leur machine en ISO/ANSI/C parceque ca marche. Et là miracle, même si ça affiche parfois n'importe quoi, ca ne casse pas tout de façon hyper chiante à debugguer.
UTF-8 est un bon format pour les documents avec des métas qui sont capables de signaler "je suis en UTF-8". mais pour les shells et les noms de fichiers, j'évite.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 5.
Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr).
Le contenu des fichiers, on s'en fout. Si le programme qui est supposé ouvrir un fichier ne gère pas UTF-8, ben soit on ouvre avec un autre programme, soit on prend sur soi et on code un pacth. Sinon recode marche du feu de dieu dans la plupart des cas.
Par contre le shell lui c'est une autre paire de manche. Si le shell est en UTF-8, ca veut dire que tout un tas d'autres trucs doivent être en UTF-8, la locale le LANG moult parmètres pour less, perl, python, ruby etc. Sinon il va se passer de drôles de trucs à l'execution de certains scripts.
Mais bon ca c'est encore gérable.
Maintenant la bonne question est "mais pourquoi je parle tout le temps de koréen ?" et bien (un élément de réponse) est là :
http://code.google.com/p/msysgit/issues/detail?id=376
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier - Aucun meta ne permet de le savoir, du moins pas sur les filesystems classiques. A partir de là pour pouvoir utiliser des programmes aussi courants que tar, git-clone, unzip, perl, python etc. il faut :
- soit se mettre d'accord avec le monde entier pour que tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
- Soit utiliser exclusivement les caractères ANSI dans tous les scripts/archives/backups/repo/sources etc.
Sinon tu prends le risques réel que ton programme fasse n'importe quoi. Supposons que ton make clean fasse un rm -r sur /home/toi/┌/obj et que ton parseur bute sur le ┌ qu'il interprete comme une terminaison (Je sais ca ne peux pas être le cas avec ce caractère là, c'est même pour ça que je l'ai choisi). Il va se passer quoi à ton avis ? Déjà ton make clean ne finira pas, et ensuite tu vas avoir plein de place libre sur ton ~….
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Autre problème, mosh utilise SSH pour se connecter à la machine distante. Sauf que en SSH il faut déclarer le type de terminal et également remaper un certain nombre de combinaisons de touches. A partir de là soit toute la chaine (emulateur terminal, serveur ssh, shell) est en UTF-8, soit je suis curieux de savoir ce qui va se passer quand je vais faire ctrl+H.
mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite)
Ce n'est pas très grave pour la discussion en cours, mais ce n'est pas moi que tu vas citer.
parce que la led num lock ne s'allume pas dans certains cas en console,
Il ne s'agit pas de la led numlock, mais de la led capslock. Ou pour être exact à cause du local echo les caractères vont s'afficher en local comme si il s'agissait d'un caps lock mais être interpretés par mosh en bout de chaine comme si il s'agissait d'un shiftlock.
Par exemple si je tape 88 via le pavée numérique en capslock chez moi, je verais s'afficher 88 sur mon emulateur terminal, mais le shell recevra deux fois l'instruction "commande précédente". Ca peut faire des trucs très drôle. Par exemple tu penses avoir lancé un worker tomcat sur le port 8088 ? Perdu tu as réexecuté la commande 3 slots plus haut et tu es passé en mode insertion.
t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
Non, quand on veut tuer UTF-8 on le présente comme la solution absolue à tous les problèmes dans tous les cas et sur toutes les machines. Alors bien sur il y a des gens qui vont y croire, mais au bout du 15ème incident incompréhensible ils vont gentillement repasser leur machine en ISO/ANSI/C parceque ca marche. Et là miracle, même si ça affiche parfois n'importe quoi, ca ne casse pas tout de façon hyper chiante à debugguer.
UTF-8 est un bon format pour les documents avec des métas qui sont capables de signaler "je suis en UTF-8". mais pour les shells et les noms de fichiers, j'évite.