![]() XTerm does not automatically set your locale. According to the xterm FAQ describing uxterm: The simplest way to start xterm using UTF-8 is via the uxterm script (which is part of the same package that includes xterm and its resource-files). It communicates with the StarNet X server (X-Win32), but the xterm process stays where it was started. The xterm process started on the RHEL server runs on that server. ![]() At least, that is the way I believe X11 works.īut that is not the way it works. turns my PC into a X terminal, and both xterm instances executes on the PC, using the X.11 protocol to communicate with the ssh instances on RHEL6. When I type in xterm in the shell on RHEL, all it does is to send a message to the X windows server on the PC, requesting that it creates another xterm process/window. I don't think any xterm process is ever running on the RHEL server. As such X-Win32 does not include one by default.Ī comment added to the question by states that ![]() Most modern Unix/Linux systems have an X based terminal emulator included in the X libraries. X-Win32 is an X Server which main purpose is to display remote graphical applications. According to StarNet's knowledgebase article Where is My Terminal Emulator? The question and followup comments indicate some confusion. But you might be able to set resources in X-Win32 if it supports that. At the time where xterm starts it is very unlikely that your X-Win32 server has the xterm* resources set. The xterm process on the Linux computer will query the X server running on your windows computer. P.P.s: I do not think setting resources in ~/.Xresources will take effect unless you merge them in with xrdb. P.s: Reading the xterm manual page I also found an easier way to achieve this: Setting LANG will make the remote xterm display UTF-8 characters properly. The solution is to run the remote xterm process like this: /usr/bin/env LANG=en_US.UTF-8 /usr/bin/xtermĮnv(1) is a utility to run a program in a modified environment. One needs to understand the difference between the remote xterm process and the shell process running inside of xterm. Including setting the LANG environment variable. ![]() However, the subshell running inside the xterm runs all setup scripts and alike. Hence the xterm process does not know that it should display characters in UTF-8. My xterm is clearly capable of this, since all non-login shells do this by default.Īt the time the sshd process on the remote computer forks to run /usr/bin/xterm there are very few environment variable set. It looks like the login shell xterm doesn't recognise the locale I've set, but I don't understand why not. Here is the relevant settings as they appear in the login shell: $ locale utf-8 characters are rendered correctly). However, after I login, I can do xterm in the login shell, and that command that will fork a new xterm instance where locale setting works as expected (i.e. Here is the command I've configured X-Win32 to use to start the login shell: xterm -u8 -ls Below is how both shells appear on my desktop, catenating a file with unicode multibye characters to the terminal. both shell instances runs in a X terminal window on the PC, and communicates with RHEL6 using the X11 protocol. If I've understood things correctly the software from rom StarNet Communications Corp implements (or emulates) a X terminal (a thin client that runs a X server). For example, here's how the string "Wilhelm Röntgen" is rendered in the two shell instances (the font used is a Unicode font and is the same font in both shell instances): Login shell: Wilhelm Röntgen My problem is that all multi-byte utf-8 characters comes out garbled in the xterm login shell. I use xterm (X-Win32 2012 Build 30 from StarNet Communications Corp) to login from a Windows 7 PC to a Red Enterprise Linux 6 (RHEL6).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |