This is the mail archive of the
mailing list for the Cygwin project.
Re: snapshot 20091002 and xterm crash
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 2 Oct 2009 13:01:42 +0200
- Subject: Re: snapshot 20091002 and xterm crash
- References: <email@example.com>
- Reply-to: cygwin at cygwin dot com
On Oct 2 09:04, Marco Atzeri wrote:
> 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 Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple