NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Setting keyboard layout on xterm



On Wed, Jun 29, 2022 at 03:20:21PM -0400, Thomas Dickey wrote:
> On Wed, Jun 29, 2022 at 05:56:09PM +0200, Martin Husemann wrote:
> > On Wed, Jun 29, 2022 at 06:21:46PM +0000, Riza Dindir wrote:
> > > I also changed the font for XTerm in the Xresources file, which uses
> > > iso8859-9, but that does not do anything. Although the font changes,
> > > the characters for that language can not be entered on xterm.
> > > 
> > > Is there a way to do that?
> > 
> > You need to set the environment variable LC_CTYPE to e.g. de_DE.ISO8859-15
> > or de_DE.UTF-8 for german (the former giving you ISO 8859-15, the latter
> > UTF8 unicode encoding), or tr_TR.ISO8859-9 or tr_TR.UTF-8 for turkish.
> > 
> > You can see all available locales in /usr/share/locale/.
> 
> just
> 	locale -a

But just "locale" shows what you are actually using.
On my test-account (not customized) for NetBSD 9.2,
the locale command shows this in uxterm:

	LANG=""
	LC_CTYPE="en_US.UTF-8"
	LC_COLLATE="C"
	LC_TIME="C"
	LC_NUMERIC="C"
	LC_MONETARY="C"
	LC_MESSAGES="C"
	LC_ALL=""

and this in xterm:

	LANG=""
	LC_CTYPE="C"
	LC_COLLATE="C"
	LC_TIME="C"
	LC_NUMERIC="C"
	LC_MONETARY="C"
	LC_MESSAGES="C"
	LC_ALL=""

Since (man locale...) LC_ALL and LANG do nothing when unset, the only
relevant setting for xterm is LC_CTYPE.  The other settings are used by
other applications.  For UTF-8 encoding, the country-code tr_TR versus
en_US.UTF-8 likewise does not matter.  It would be relevant (to other
applications) if it were not UTF-8.  xterm uses the locale environment
which is set outside to decide whether to use UTF-8 encoding.  It's
possible to configure xterm to allow switching after startup, but most
users don't want or need that.

If xterm were started like this:

	setenv LC_CTYPE en_US.UTF-8
	xterm

or

	setenv LC_ALL en_US.UTF-8
	xterm

then the two outputs (from uxterm and xterm) would be the same.  The
display (using the bitmap font) looks the same with either uxterm or
xterm started with a locale tweak.  Both, by the way, use a less
complete font than Debian packages for the same XLFD.  You'll probably
be better off using TrueType with NetBSD.

While answering this question, I set my locale as described above,
and the keyboard behaved as expected when using Turkish layout.
The keys (seen with "cat -v") matched the picture which I obtained
using these commands:

	setxkbmap -layout tr
	xkbprint -color "${DISPLAY}" - | ps2pdf - > tr_keyboard_layout.pdf

The "setlocale" manpage is usually the place to go to see how the locale
environment variables are used.  Looking now, I see that NetBSD does
this in nls(7):

	The environment variable settings are queried by their priority
	level in the following manner: 
	...

The Open Group expands on the environment variables here:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

LANG
	This variable shall determine the locale category for native
	language, local customs, and coded character set in the absence
	of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES,
	LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables.  This
	can be used by applications to determine the language to use for
	error messages and instructions, collating sequences, date
	formats, and so on.
LC_ALL
	This variable shall determine the values for all locale
	categories.  The value of the LC_ALL environment variable has
	precedence over any of the other environment variables starting
	with LC_ (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
	LC_NUMERIC, LC_TIME) and the LANG environment variable.
LC_CTYPE
	This variable shall determine the locale category for character
	handling functions, such as tolower(), toupper(), and isalpha(). 
	This environment variable determines the interpretation of
	sequences of bytes of text data as characters (for example,
	single as opposed to multi-byte characters), the classification
	of characters (for example, alpha, digit, graph), and the
	behavior of character classes.  Additional semantics of this
	variable, if any, are implementation-defined.

-- 
Thomas E. Dickey <dickey%invisible-island.net@localhost>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index