12-16-2013 12:07 PM
I have an HP-UX 11.23 box where I have added to a user .profile the following lines:
when I execute this command :
I get the following output :
I connect to this server with putty (the remote character set is set to utf8)
As soon as I'm connected, if I type the charactère é or è (something with accents) I get awkward values like )C
I have spend the day on it with no luck, if anyone can help ?
12-16-2013 05:30 PM
One of the most challenging aspects of special characters that are not part of the ASCII collection is how to represent the 'other' characters. Although HP-UX offers locales to attempt to standarize the methods, PuTTY implements a fairly narrow range of font extensions but doesn't offer any standard names for the extensions. I would try changing the 'Script' dropdown box found in the Window -> Appearance -> Change option. It looks like "Central European" may be a match.
12-17-2013 01:53 AM
No it didn't work.
What is strange is that in putty under the login prompt when I type a character with accents it works like : login:éééé
but as soon as I'm logged in, when I type é it is replaced by C)
12-17-2013 08:06 AM
Your shell and/or stty settings might be stripping off the 8th bit on accented characters, but the login prompt is 8-bit clean and echoes everything back as-is.
When UTF-8 encoding is used and the 8th bit is stripped off from non-US-ASCII characters, you get a random-seeming group of two or more US-ASCII characters for each non-US-ASCII character.
Things to check:
- stty settings: run "stty -a" to check. You'll want "-parenb", "cs8", and "-istrip". Note the minus signs. If your "stty -a" output says "istrip" without the minus sign, run "stty -istrip" to fix it for the current session. You can add this to /etc/profile or your personal login script.
- shell: At least on some HP-UX versions, the default shell /usr/bin/sh supports locales, but only if the locale variables are already set up when the shell starts up... and if the locale variables are set in /etc/profile, the shell is already running when the variables are set.
To test for this, first make sure that your stty settings and locale variables are correct, then run "exec $SHELL". If this fixes it, note that you cannot just add this into /etc/profile without causing an endless loop.
Alternative ways to get around this problem:
- use another shell: for example, /usr/bin/ksh seems to handle the locale environment variables in a smarter way (i.e. it detects changes to locale environment variables in the current session and makes the appropriate setlocale() calls for itself).
- if you are logging in with SSH, make sure that PermitUserEnvironment is set in /opt/ssh/etc/sshd_config, and put the locale environment settings to $HOME/.ssh/environment file: the sshd daemon will read the file and set the variables before actually starting your shell, so localized /usr/bin/sh will work.