Problème affichage script bash (charset)
Lineo
-
Lineo -
Lineo -
Bonjour,
Je suis entrain de faire sur un serveur linux un script bash qui affiche à l'écran différentes choses, en français avec les accents et tout.
Mon problème est que de nombreux utilisateurs vont se connecter en ssh sur ce serveur et exécuter ce script, et selon que leur terminal soit configuré en ISO,ANSI,UTF-8,... le résultat ne sera pas le même notamment pour l'affichage des accents !
Si j'encode mon script en ISO, les utilisateurs UTF8 ne verront pas les accents, et si je l'encode en UTF8, ceux en ISO ne les verront pas. Et des caractères "bizarres" apparaissent.
Comment pourrais-je remédier à ce problème et toujours faire le bon affichage en fonction du terminal?
Merci d'avance
Je suis entrain de faire sur un serveur linux un script bash qui affiche à l'écran différentes choses, en français avec les accents et tout.
Mon problème est que de nombreux utilisateurs vont se connecter en ssh sur ce serveur et exécuter ce script, et selon que leur terminal soit configuré en ISO,ANSI,UTF-8,... le résultat ne sera pas le même notamment pour l'affichage des accents !
Si j'encode mon script en ISO, les utilisateurs UTF8 ne verront pas les accents, et si je l'encode en UTF8, ceux en ISO ne les verront pas. Et des caractères "bizarres" apparaissent.
Comment pourrais-je remédier à ce problème et toujours faire le bon affichage en fonction du terminal?
Merci d'avance
A voir également:
- Problème affichage script bash (charset)
- Script vidéo youtube - Guide
- Affichage double ecran - Guide
- Problème affichage fenêtre windows 10 - Guide
- Mas script - Accueil - Windows
- Windows 11 affichage classique - Guide
14 réponses
Essaye de filtrer la sortie de ton script (stdout et stderr) avec iconv, après avoir déterminé l'encodage du terminal courant.
man 1 iconv
man 1 iconv
Merci, c'est justement ce que je suis entrain de faire
Le problème c'est que du coup ça ressemble plutôt à du bricolage,
et je me demandais s'il n'y avait pas une solution plus propre voir "officielle" ?
Le problème c'est que du coup ça ressemble plutôt à du bricolage,
et je me demandais s'il n'y avait pas une solution plus propre voir "officielle" ?
Salut,
Et en s'attaquant au problème à la base ?
Côté utilisateur avec luit ?
https://www.nozav.org/archives/blog//post/2009/09/03/Probl%c3%a8me-d-encodage-dans-des-session-SSH
Et en s'attaquant au problème à la base ?
Côté utilisateur avec luit ?
https://www.nozav.org/archives/blog//post/2009/09/03/Probl%c3%a8me-d-encodage-dans-des-session-SSH
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Pour l'instant je mets en iso-8859-15 par défaut , et je regarde d'abord dans $LC_ALL, puis dans $LANG (si LC_ALL vide) s'il y a "utf-8"/i , et là je convertis en UTF-8
Mais je n'ai pas l'impression de faire quelque chose de bien
N'y-a t-il pas une commande qui nous retourne le bon encodage à utiliser ?
Mais je n'ai pas l'impression de faire quelque chose de bien
N'y-a t-il pas une commande qui nous retourne le bon encodage à utiliser ?
N'est-il pas possible d'"émuler" un envoi d'une lettre accentuée par le terminal ?
Il suffirait alors de regarder en quoi elle est encodée et le tour serait joué, sans aucun risque de se tromper !!
Il suffirait alors de regarder en quoi elle est encodée et le tour serait joué, sans aucun risque de se tromper !!
Oui mais il faudrait faire ça comme si le echo avait été tapé au clavier dans le terminal de l'utilisateur
Là tu me proposes de faires un echo dans le script, si je fais ça, ce sera en UTF8 si mon script est encodé en utf8 par mon éditeur de texte, et en ISO-X s'il est encodé en ISO-X.
Mais ce n'est pas du tout l'encodage du terminal de l'utilisateur.
Là tu me proposes de faires un echo dans le script, si je fais ça, ce sera en UTF8 si mon script est encodé en utf8 par mon éditeur de texte, et en ISO-X s'il est encodé en ISO-X.
Mais ce n'est pas du tout l'encodage du terminal de l'utilisateur.
Peut être avez vous au moins une piste à me donner pour que j'y arrive ?
Merci d'avance.
Désolé d'insister peut-être un peu trop :-)
Merci d'avance.
Désolé d'insister peut-être un peu trop :-)
tester l'environnement comme au post #6 me semble une bonne méthode.
sinon pour simuler une touche clavier, il y a xdotool : http://www.tux-planet.fr/xdotool-simulation-du-clavier-et-de-la-souris-sous-linux/
sinon pour simuler une touche clavier, il y a xdotool : http://www.tux-planet.fr/xdotool-simulation-du-clavier-et-de-la-souris-sous-linux/
Merci,
Hélas je doute que ça fonctionne, ça va simuler des touches sur le serveur, et pas sur les clients.
Il me faudrait un équivalent à
echo "Veuillez saisir un é :"
#L'utilisateur distant saisit 'é' et valide
read var
Mais sans que l'utilisateur ait à saisir ce é :]
Ou avec une autre méthode !
Le but est de connaitre l'encodage effectif utilisé par le terminal de l'utilisateur.
$LANG et $LC_ALL ne reflètent pas forcément la réalité, surtout dans mon cas.
Pour rappel :
L'utilisateur se connecte en ssh (terminal linux distribution X, putty,... ) sur mon serveur et lance le script.
Je peux faire des modifs sur le serveur et dans le script mais je n'ai pas de contrôle sur les postes des utilisateurs.
Hélas je doute que ça fonctionne, ça va simuler des touches sur le serveur, et pas sur les clients.
Il me faudrait un équivalent à
echo "Veuillez saisir un é :"
#L'utilisateur distant saisit 'é' et valide
read var
Mais sans que l'utilisateur ait à saisir ce é :]
Ou avec une autre méthode !
Le but est de connaitre l'encodage effectif utilisé par le terminal de l'utilisateur.
$LANG et $LC_ALL ne reflètent pas forcément la réalité, surtout dans mon cas.
Pour rappel :
L'utilisateur se connecte en ssh (terminal linux distribution X, putty,... ) sur mon serveur et lance le script.
Je peux faire des modifs sur le serveur et dans le script mais je n'ai pas de contrôle sur les postes des utilisateurs.
salut,
et en cherchant du côté de la configuration du daemon ssh (sur le serveur, donc) : commenter AcceptEnv dans /etc/ssh/sshd_config ?
et en cherchant du côté de la configuration du daemon ssh (sur le serveur, donc) : commenter AcceptEnv dans /etc/ssh/sshd_config ?
Salut,
j'avais regardé par là aussi, mais AcceptEnv ou pas le problème reste le même, ça peut même être pire car si le système à un encodage par défaut($LANG) différent du terminal de l'utilisateur, celui ci verra tout dans le mauvais charset avec les conséquences que l'on connait sur les accents :(
Avec gnome-terminal par exemple, il est facile de changer l'encodage des caractères, et là le terminal est indépendant de AcceptEnv, $LANG, $LC_ALL.
En général ces variables donnent juste une valeur par défaut de départ, qui peut être prise en compte ou pas, et changer par la suite, surtout lors de multiples ssh sur des serveurs différents, ou après un su -, ces variables sont souvent susceptibles de changer.
Donc dans mon cas d'utilisation, elles ne sont pas fiables du tout
j'avais regardé par là aussi, mais AcceptEnv ou pas le problème reste le même, ça peut même être pire car si le système à un encodage par défaut($LANG) différent du terminal de l'utilisateur, celui ci verra tout dans le mauvais charset avec les conséquences que l'on connait sur les accents :(
Avec gnome-terminal par exemple, il est facile de changer l'encodage des caractères, et là le terminal est indépendant de AcceptEnv, $LANG, $LC_ALL.
En général ces variables donnent juste une valeur par défaut de départ, qui peut être prise en compte ou pas, et changer par la suite, surtout lors de multiples ssh sur des serveurs différents, ou après un su -, ces variables sont souvent susceptibles de changer.
Donc dans mon cas d'utilisation, elles ne sont pas fiables du tout