|
Home > Archive > Unix Shell > December 2006 > Character set conversion (through ssh)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Character set conversion (through ssh)
|
|
| Jellby 2006-12-24, 1:16 pm |
| Hi all,
I have a server with Mandriva 2007, which is set up to use utf-8 as a
default charset, that means the shell uses utf-8 and text files are created
as utf-8 by default.
My home computer is a little bit older and uses iso-8859-15. When I connect
with ssh to the server, I get non-ASCII characters in the terminal all
messed up, and it's even worse if I want to edit a text file, because I
don't even know what I'm writing.
I once had the reverse problem: a server with iso-8859-15 and a client with
utf-8, and I could solve it by using "luit ssh server.address". However,
luit does not seem to do the inverse conversion.
Does anyone have any idea for solving this? I'm sure many others have
already suffered this same problem (but I couldn't find a solution in
google). I tried with something like this in my ~/.bashrc file (in the
server):
if [ -n "SSH_CLIENT" ]; then
export LANG=es_ES.ISO-8859-15
export LC_ALL=es_ES.ISO-8859-15
fi
and this does solve the problem with the terminal messages (or so it seems),
but the text files are still mangled with vi, for instance.
I've seen that, if I don't include the above code, I can get the right
behaviour with vi by setting "termencoding=iso-8859-15". With the code
in .bashrc I have to set "encoding=utf-8" as well. This would be OK if I
could set this in a configuration file, but I dont want it to be permanent,
since I will be using the server itself too (no remote connection) and I
could also use other clients with utf-8 configuration.
So, this is all a mess, I guess it could be solved if there was some kind of
"charset" option in .ssh/config, but there isn't. Or if there was something
like an inverse luit, but I didn't find it. Do you have any other
suggestion?
Thanks in advance.
--
Ignacio __ Fernández Galván
/ /\
Linux user / / \ PGP Pub Key
#289967 / / /\ \ 0x01A95F99
/ / /\ \ \
http://djelibeibi.unex.es
/________\ \ \
jellby \___________\/ yahoo.com
| |
| Bill Marcum 2006-12-24, 7:19 pm |
| On Sun, 24 Dec 2006 18:25:58 +0100, Jellby
<me@privacy.net> wrote:
>
>
> Hi all,
>
> I have a server with Mandriva 2007, which is set up to use utf-8 as a
> default charset, that means the shell uses utf-8 and text files are created
> as utf-8 by default.
>
> My home computer is a little bit older and uses iso-8859-15. When I connect
> with ssh to the server, I get non-ASCII characters in the terminal all
> messed up, and it's even worse if I want to edit a text file, because I
> don't even know what I'm writing.
>
> I once had the reverse problem: a server with iso-8859-15 and a client with
> utf-8, and I could solve it by using "luit ssh server.address". However,
> luit does not seem to do the inverse conversion.
>
> Does anyone have any idea for solving this? I'm sure many others have
> already suffered this same problem (but I couldn't find a solution in
> google). I tried with something like this in my ~/.bashrc file (in the
> server):
>
> if [ -n "SSH_CLIENT" ]; then
> export LANG=es_ES.ISO-8859-15
> export LC_ALL=es_ES.ISO-8859-15
> fi
>
> and this does solve the problem with the terminal messages (or so it seems),
> but the text files are still mangled with vi, for instance.
>
> I've seen that, if I don't include the above code, I can get the right
> behaviour with vi by setting "termencoding=iso-8859-15". With the code
> in .bashrc I have to set "encoding=utf-8" as well. This would be OK if I
> could set this in a configuration file, but I dont want it to be permanent,
> since I will be using the server itself too (no remote connection) and I
> could also use other clients with utf-8 configuration.
>
> So, this is all a mess, I guess it could be solved if there was some kind of
> "charset" option in .ssh/config, but there isn't. Or if there was something
> like an inverse luit, but I didn't find it. Do you have any other
> suggestion?
>
"vi" could be an alias or symlink for vim, elvis, nvi or something else.
If you check the man page, there is probably an option to select a
different config file or to set config options on the command line. You
can use that to create an alias or function in .bashrc so vi behaves
differently depending on $LANG.
--
"You boys lookin' for trouble?"
"Sure. Whaddya got?"
-- Marlon Brando, "The Wild Ones"
| |
| Jellby 2006-12-26, 7:20 pm |
| Among other things, Bill Marcum saw fit to write:
> "vi" could be an alias or symlink for vim, elvis, nvi or something else.
> If you check the man page, there is probably an option to select a
> different config file or to set config options on the command line. You
> can use that to create an alias or function in .bashrc so vi behaves
> differently depending on $LANG.
Thanks, I always forget "vi" is not the real program. I think I have it
working like this:
In the server, in ~/.bashrc I have
if [ -n "$SSH_TTY" ]; then
export LANG=es_ES.ISO-8859-15
export LC_ALL=es_ES.ISO-8859-15
fi
and in ~/.vimrc, these lines:
if match($LANG,'ISO-8859-15') > -1
set encoding=utf-8
set termencoding=iso-8859-15
endif
In this way, when I connect from outside, I have a latin1 environment and
terminal, but vim still assumes utf8 files.
However, I don't think this solution is optimal, because the configuration
should be in the client and not in the server, I might connect from a utf8
client, and then I don't want the .bashrc stuff, but well, it's good enough
for the moment.
--
Ignacio __ Fernández Galván
/ /\
Linux user / / \ PGP Pub Key
#289967 / / /\ \ 0x01A95F99
/ / /\ \ \
http://djelibeibi.unex.es
/________\ \ \
jellby \___________\/ yahoo.com
|
|
|
|
|