This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: snapshot 20091002 and xterm crash

[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= 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:


However, even though newlib handles "UTF8" same as "UTF-8", it's
apparently not the same for xterm.  This fails:


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
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]