On Fri, 20 Jan 2023, Valery Ushakov wrote:
On Fri, Jan 20, 2023 at 15:09:44 +0100, r0ller wrote:
Well, checking what printf results in, I get:
$printf 'n?z'|hexdump -C
00000000 6e e9 7a |n.z|
00000003
$printf $'n\uE9z'|hexdump -C
00000000 6e c3 a9 7a |n..z|
00000004
It's definitely different from what you got for 'n?z'. What does
that mean?
In the second example you specify \uE9 which is the unicode code point
for e with acute. It is then uncondionally converted by printf to
UTF-8 (which is two bytes: 0xc3 0xa9) on output.
Your terminal input is in 8859-1 it seems.
That's it. The terminal emulator is not generating UTF-8 from the keyboard
input.
May be you need to specify -u8 option or utf8 resource?
That would work. So would running uxterm instead of xterm, but, all of
these mess-up command-line editing: Alt+key is converted into a char.
code instead of an ESC+key sequence.
R0ller, do this:
1. Add your locale settings in ~/.xinitrc (or ~/.xsession if using xdm):
export LANG=hu_HU.UTF-8
export LC_CTYPE=hu_HU.UTF-8
export LC_MESSAGES=hu_HU.UTF-8
2. In ~/.Xresources, tell xterm to use the current locale when generating
chars.:
XTerm*locale: true
The `-lc' option does the same thing. If using uxterm, the class-name
becomes `UXTerm'.
On Fri, 20 Jan 2023, Robert Elz wrote:
I believe bash will take your current locale into account
when doing that [...]
That's correct. But as r0ller had a UTF-8 locale set, I didn't mention
that.
However, it is better to be precise, so thank you!
-RVP