À mon tour d'avoir un soucis de locale, le système est bien en français mais ce sont les caractères accentués qui ne fonctionnent pas. Uniquement quelques fois dans le term et continuellement dans les tty...
Voilà ce que donne la commande locale -a (on voit bien le ç qui s'affiche en point d'interrogation
On peut voir la sortie de la commande locale depuis un tty et depuis une console de l'interface graphique (Si pour ton utilisateur et root la sortie n'est pas la même merci de donner les 2) ainsi que le contenu du rc.conf
Pourrais tu relire ce que je t'ai demandé ? Et comparer avec ce que tu as donné ? Quel est l’intérêt de donner 2 fois la même chose ?
C'est la sortie depuis un tty ou depuis une console de ton interface graphique ?
hansi a écrit : Uniquement quelques fois dans le term et continuellement dans les tty...
Vu que tes locales sont correctes, avant d'aller plus loin, c'est quand tu fais quoi exactement ? Parce qu'un fichier encodé en iso par exemple, c'est normal que ça te sorte des symboles cabalistiques en console (ex: locale -a m'a toujours retourné fran�ais et je suis bien en utf8 aussi).
«The following statement is not true. The previous statement is true.»
Alors je ne sais plus précisément mais en général c'est quand j'installe/compile un programme et qu'il répond des phrases dans le term.
Mais le plus génant c'est vraiment dans les tty, quand je reboot ou autre on voit bien que tous les messages des programmes et d'Xfce sont avec des symboles bizarres.
Le truc c'est que ça ne le faisait jamais avant (avant le changement au niveau du locale.sh je présume)
Combattu souvent, battu parfois, abattu jamais ! (François de Charette)
FoolEcho a écrit :Faudrait en savoir plus, mais là ça peut être ce que je disais.
Dès que je rerecontre le soucis je viens poster mais tu dois avoir raison.
FoolEcho a écrit :Le locale.sh (tu en as un ? si oui, c'est lui qui prend le pas sur le rc.conf) n'a d'utilité que si tu as un shell spécial, genre zsh. C'est le cas ?
Non pas de shell spécial, j'ai bien ce fichier et j'en parlais car il y a un moment il y avait une news à ce sujet, un changement à faire pour la mise à jour, et je crois bien que c'est à partir de ce moment là que le problème est apparu...
Et sinon ça ne pourrait pas être du au kernel linux-ck ? Un truc à configurer avant sa compilation ?
Combattu souvent, battu parfois, abattu jamais ! (François de Charette)
hansi a écrit :un changement à faire pour la mise à jour, et je crois bien que c'est à partir de ce moment là que le problème est apparu...
Le changement concernait locale.conf (et pas .sh même si ça va avec) avec certains shells ... mais de toutes manières tes locales sont correctes pour ce qu'on en voit.
hansi a écrit :Et sinon ça ne pourrait pas être du au kernel linux-ck ? Un truc à configurer avant sa compilation ?
Je ne sais pas. Bien possible (si possible, tu n'as qu'à démarrer sur le noyau officiel et voir si c'est mieux).
«The following statement is not true. The previous statement is true.»
FoolEcho a écrit :
Le locale.sh (tu en as un ? si oui, c'est lui qui prend le pas sur le rc.conf) n'a d'utilité que si tu as un shell spécial, genre zsh. C'est le cas ?
En fait non : zsh s’accommode très bien de l'ancien système de rc.conf pour LOCALE.
Ce problème survient avec des messages et/ou lorsque tu édites un fichier ?
Si par hasard un "cat" <fichier> ne te sort pas d'accent, vérifie son encodage par :
nope le problème n'est présent que dans certains messages et dans les tty.
Une fois X lancé et dans Xfce tout fonctionne normalement, les fichiers peuvent contenir tous les accents possibles et imaginables même dans le nom, ça roule mais uniquement depuis Xfce...
Si en revanche je créé un fichier "éssài" dans mon home et que depuis les tty je fais "ls -a ./" là en effet tous les carractères spéciaux sont couillés. Idem si je fais "nano éssài", la ligne de commande affiche bien les accents mais le titre du fichier a les accents buggués une fois nano lancé...
INCOMPRÉHENSIBLE !!!
Combattu souvent, battu parfois, abattu jamais ! (François de Charette)
En TTY (ctrl+alt+f2), avec un "ls -lA" : il n'y a que les caractères composés, comme Alt-Gr + o = œ, qui apparaissent sous forme de rectangle, si l'encodage est utf8. Par contre pour tout autres types cat ou ls même combat, pas d'affichage.
Dans mon rc.conf j'ai :
FoolEcho a écrit :
Le locale.conf (tu en as un ? si oui, c'est lui qui prend le pas sur le rc.conf) n'a d'utilité que si tu as un shell spécial, genre zsh. C'est le cas ?
En fait non : zsh s’accommode très bien de l'ancien système de rc.conf pour LOCALE.
J'avions cru.
«The following statement is not true. The previous statement is true.»
karhu a écrit :En TTY (ctrl+alt+f2), avec un "ls -lA" : il n'y a que les caractères composés, comme Alt-Gr + o = œ, qui apparaissent sous forme de rectangle, si l'encodage est utf8. Par contre pour tout autres types cat ou ls même combat, pas d'affichage.
Dans mon rc.conf j'ai :
J'ai essayé de changer de disposition de clavier, de régler CONSOLEMAP et de faire les manips décrites ici : https://wiki.archlinux.org/index.php/Fo ... fault_font et ça n'a rien changé...
C'est tellement exaspérant que je vais lacher l'affaire même si à mon avis il y a forcément une solution
Combattu souvent, battu parfois, abattu jamais ! (François de Charette)
Ça donne la même impression que sur le sujet cité par karhu: tu devrais vérifier comment sont encodés tes fichiers (file -i pour le contenu, echo du nom de fichier dans un fichier de sortie pour vérifier l'encodage des noms de fichiers à problème.
«The following statement is not true. The previous statement is true.»
Un petit test, avec vim (pas un éditeur de texte) crée un fichier avec des accents dans le titre et dans le texte et regarde dans un tty et sous X le résultat d'un "cat" et d'un "file -i".
Edit : j'ai rajouté le deuxième fichier et c'est étrange car "Ç" est composé à l'aide de Alt-r+shift+ç donc il aurait du se comporer comme œ !
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
