Mail Archives: cygwin/2009/10/02/07:02:04
[Ping Yaakov]
On Oct 2 09:04, Marco Atzeri wrote:
> Hi,
>
> xterm abort when run in snapshot 20091002
> reverting to 20090924 solve the issue.
>
> Run as:
> DISPLAY=127.0.0.1:0.0 xterm -ls /usr/bin/bash.exe
I can reproduce that. I found the problem and it's really puzzeling.
In the snapshot 2009-10-02, the default charset for the "C" locale is
set to UTF-8 for the application. In 2009-09-24, it was only using
UTF-8 for filenames and other system objects by default.
When starting xterm with no locale environment variable set, it fails
to start. If you're quick enough, you can read a message along the
lines of "Cannot allocate pty: No such file ..."
However, starting xterm works if you set, for instance, the environment
variable $LANG to "C.UTF-8". This works:
DISPLAY=127.0.0.1:0.0 LANG=C.UTF-8 xterm
However, even though newlib handles "UTF8" same as "UTF-8", it's
apparently not the same for xterm. This fails:
DISPLAY=127.0.0.1:0.0 LANG=C.UTF8 xterm
Yaakov, do you have a debug version of xterm handy? Would you mind
trying to figure out why xterm is so sensitive in terms of the UTF-8
charset usage? What's especially weird is the fact that no native
characters are used anywhere, only the ASCII range. Why xterm should
fail, and why it's supposedly unable to open a pty with a "no such file
or directory" message beats me.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -