[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
