How can I input German characters from telnet/ssh

[Carrie Yi]

I have set the locale by doing the following steps:
1. edit /etc/rc.config.d/LANG,
LANG=de_DE.iso88591;export LANG
2. edit /etc/profile
LANG=de_DE.iso88591;export LANG
3. reboot
Then I tried to connect this box from a German Windows with putty.exe. All German characters (in file/output)are displayed well. But I couldn't input any German specific characters. All the accented characters are converted to garbage chars.
I have set "character set translation on received data" to "ISO-8859-1:1998 (Latin-1, West Europe)" for the putty utility.
How could I input German characters properly?

[Matti_Kurkela]

I know at least two possible causes for such a problem.

Does it happen in the shell prompt only, or in applications too? In other words, if you start an editor (like vi for example), can you use accented characters when editing the file?

One possible cause would be incorrect stty settings: use the "stty -a" command to check the settings.
The 8-bit character mode should be selected, and the 8th bit stripping option should be disabled, i.e. the "stty -a" listing should include the tokens "cs8" and "-istrip".

If it says "istrip" without the minus sign, the tty driver is stripping the 8th bit from any accented characters you type, changing the ISO-8859-1 character "a-with-dots" to "d" and the "o-with-dots" character to "v".
Due to the structure of the ISO-8859-1 character set, this change happens the same way in both upper and lower cases.

The other possible cause is somewhat shell-specific. Which shell are you using?

The HP-UX default shell, /usr/bin/sh, obeys the standard locale environment variables like LANG... but there is a trick: the locale variable(s) must be set up _before_ the shell starts.

If the variables are initialized in /etc/profile or whatever, it will work just fine in applications, but at that time the shell has already initialized its own locale settings. You'll need a way to set the variable *before* the shell starts up.

Normally the variables set in /etc/rc.config.d/LANG would be inherited by the system daemons, and ultimately the login sessions too... but sshd tries to be safe and resets the environment variable space to very minimalistic default values before initializing the user session. Good-bye LANG.

If you use SSH to log in, there is a way:

1.) Make sure that the server's /opt/ssh/etc/sshd_config file has the option PermitUserEnvironment enabled. (I think that's the default in HP Secure Shell).

2.) Create the ~/.ssh sub-directory to your home directory, if it does not already exist.

3.) Create the file ~/.ssh/environment, and put in the necessary locale environment variable setting(s), e.g.:

LANG=de_DE.iso88591

The export command is not needed here: all the variables defined in this file will automatically be exported to the SSH session by the sshd process, _before it starts the shell for the SSH session_.

(The ~/.ssh/environment file is _not_ interpreted as a shell script: it is simply a list of desired environment variables and their values.)

MK

[Carrie Yi]

hi MK,
Thank you for your reply.
I checked the output of "stty -a". it says istrip without minus. And it did convert character "a-with-dots" to "d" and the "o-with-dots" character to "v".
# stty -a
speed 38400 baud; line = 0;
rows = 24; columns = 80
min = 1; time = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U
eof = ^D; eol = ^@; eol2 ; swtch
stop = ^S; start = ^Q; susp ; dsusp
werase ; lnext
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crts
-ignbrk brkint -ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
ixon ixany ixoff -imaxbel -rtsxoff -ctsxon -ienqak
isig icanon -iexten -xcase echo echoe echok -echonl -noflsh
-echoctl -echoprt -echoke -flusho -pendin
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel -tostop tab3

What I did:
#stty -istrip
After that, if I input o-with-dots it is displayed as "^ö". So do copy and paste. However, the system accepts it as ö.
Do you have any advice for this?

[Carrie Yi]

sorry, the last paragragh is:

What I did:
#stty -istrip
After that, if I input o-with-dots it is displayed as "^o-with-dots"(with ^ ahead). So do copy and paste. However, the system accepts it as o-with-dots(without ^).
Do you have any advice for this?

[Matti_Kurkela]

OK, so that was a step in the correct direction, but not a complete solution yet.

You might actually have had a combination of the two problems I listed originally.

"stty -istrip" fixed the first part of the problem: it made the TTY driver stop forcing the 8th bits of all incoming characters to zero.

You might want to add the "stty -istrip" command to /etc/profile and /etc/csh.cshrc, so that it'll be automatically executed for all users. Unless you have ancient 7-bit-only terminals connected to your system, this setting should not harm any of your users.

Now it seems that the something (maybe the shell?) still regards the characters with 8th bit set as strange control codes, and not regular ISO-8859-1 printable characters.

But if you have the LANG variable properly set in /etc/profile, anything except your initial login shell should handle accented characters just fine. In fact, even the shell should accept the accented characters if you start a second shell within your session: i.e. simply enter the command

sh

to enter a "shell-within-a-shell". The inner shell had the LANG already set up as it started, so it should have no problems with accented characters. Type "exit" to return to your regular session, and the problem with accented characters should re-appear. If your system behaves like this, implement the ~/.ssh/environment trick I described in my first response.

MK

[Carrie Yi]

hi MK,
It is solved after change sh to csh. Thank you very much.
Carrie.