Operating System - HP-UX
1748114 Members
3467 Online
108758 Solutions
New Discussion юеВ

Re: Wrong character mapping in console mode

 

Wrong character mapping in console mode

Hi all,

I have an HP workstation working under HP-UX 11.11. The keyboard layout ist set to USB_PS2_DIN_German_Euro

Wenn I log in in console mode, the TERM variable is set to 'hp'. Unfortunately, some characters don't appear as they should be.

Especially annoying is the minus character. It actually works like a minus (-) but appears on the screen like a caret (^).

Also as I'm using the tcsh, the arrow keys should allow me to scroll through the history but they don't work at all.

Thanks.
13 REPLIES 13
Matti_Kurkela
Honored Contributor

Re: Wrong character mapping in console mode

> Especially annoying is the minus character. It actually works like a minus (-) but appears on the screen like a caret (^).

This is very strange, as both minus and caret are part of the basic 7-bit ASCII character set, which is unchanged in most 8-bit character sets.

If the minus sign actually appears like a caret, the problem might be that the font used on the display uses a different character encoding than the keyboard layout. But I don't know any character set which would make such a deviation in the basic ASCII set.

Could you please run the following commands and tell us what is the output in each case?

expr 2 ^ 3

expr 2 - 3

> Also as I'm using the tcsh, the arrow keys should allow me to scroll through the history but they don't work at all.

tcsh is not part of standard HP-UX 11.11, so it's probably been installed from a third-party source. Perhaps the packager did not modify the shell's defaults to include the HP arrow key definitions?

The standard tcsh has a built-in mapping for ANSI/vt100-style arrow keys. This includes xterm, so in X11 environment the arrow keys will work automatically. As vt100 is one of the most common terminal emulations, it is likely that the arrow keys will work on most common remote connections too. But the HP terminals' arrow key definitions are not built in.

By default, tcsh does not use TERM, but the older TERMCAP variable. The TERMCAP variable should include the entire terminal feature description, not just the name of the terminal. If you use tcsh and that version has not been extensively modified to use the terminfo library instead of termcap, you probably should add some commands to your login scripts to populate the TERMCAP variable, as HP-UX does not do it by default.

If TERMCAP is populated correctly, tcsh should automatically get the terminal-type-specific arrow key mappings from it. Failing that, the "bindkey" command could be used to explicitly force the key mappings.

MK
MK

Re: Wrong character mapping in console mode

> Could you please run the following commands and tell us what is the output in each case?
> expr 2 ^ 3
> expr 2 - 3

Both produce 2^3 as output.


> If TERMCAP is populated correctly, tcsh should automatically get the terminal-type-specific arrow key mappings from it

OK, interesting hint. I will delve somewhat into TERMCAP.

Re: Wrong character mapping in console mode

> If the minus sign actually appears like a caret, the problem might be that the font used on the display uses a different character encoding than the keyboard layout. But I don't know any character set which would make such a deviation in the basic ASCII set.

How can I find out which font and which encoding is beeing used?

Matti_Kurkela
Honored Contributor

Re: Wrong character mapping in console mode

>> expr 2 ^ 3
>> expr 2 - 3

>Both produce 2^3 as output.

Sorry, I should have mentioned that all the spaces are essential.

If entered exactly as I wrote them, with spaces separating each character after "expr", one of these should output "-1" and the other "expr: syntax error". The question is, which one?

> How can I find out which font and which encoding is beeing used?

It's been too long since I seriously worked with HP-UX _workstations_... but as you said you're logging in console mode (aka Internal Terminal Emulator, or ITE), the name of the font is probably known only by the hardware/firmware developers.

In ITE, if my hazy memory is correct, the (default) character encoding is HP Roman8. That would not explain the discrepancy between the caret and the minus sign: in that character set, both of those characters conform to standard ASCII.

But if you're using the console in GUI mode, the character set can be selected in the login dialog. If you choose a non-default language and/or character set when logging in, your choice will automatically be remembered the next time you log in.

MK
MK

Re: Wrong character mapping in console mode

> Sorry, I should have mentioned that all the spaces are essential.

>If entered exactly as I wrote them, with spaces separating each character after "expr", one of these should output "-1" and the other "expr: syntax error". The question is, which one?

*) If I type in: expr 2 ^ 3 (with the caret key), the output is:

hostname:> expr 2 ^ 3
expr: Syntax error

*) If I type in: expr 2 - 3 (with the minus key), the output is:

hostname:> expr 2 ^ 3
^1


Hope this helps.
Dennis Handly
Acclaimed Contributor

Re: Wrong character mapping in console mode

>*) If I type in: expr 2 ^ 3: expr: Syntax error
>*) If I type in: expr 2 - 3: hostname:> expr 2 ^ 3: ^1

Hmm, so two different inputs produce the same char on the screen but they are different.

So these would show the same char (^) but different hex values:
echo "-" | xd -tx1 -tc
echo "^" | xd -tx1 -tc

Re: Wrong character mapping in console mode

>So these would show the same char (^) but different hex values:
>echo "-" | xd -tx1 -tc
>echo "^" | xd -tx1 -tc

OK, this was a bit complicated to test because it appeared that the pipe character doesn't work. So from a remote host I put the 2 commands in a script and then ran it on the local console.

This is the result:

*) with the minus key:
0000000 2d a
^ Zn
0000002

*) with the caret key:
0000000 5e a
^ Zn
0000002


As you can see, the backslash (\) is also affected as it appears on the screen as "Z"


Re: Wrong character mapping in console mode

I meanwhile found out that the above behaviour only occurs if the keyboard layout is set to something other than US_English.

With US_English layout, the appearance on the screen correlates with the keys. With German or French e.g., a few keys show differently on the screen but are interpreted correctly as typed in.

Could this be some locale or language bug? Is there maybe a patch for it?

Regards

Re: Wrong character mapping in console mode

Hello,

no reaction for more than 10 days. The problem still exists. Does really no one have an an idea about my 2 previous postings.

Regards