[Patch] Clear button for setup.exe package search
Add a button to clear the setup.exe package search filter. ChangeLog: 2009-05-08 Bryan Thrall bryan.thr...@flightsafety.com * choose.cc (ChooserPage::OnMessageCmd): Clear search filter when clear button clicked. * res.rc (IDD_CHOOSE_DIALOG): Add IDC_CHOOSE_CLEAR_SEARCH button. * resource.h (IDC_CHOOSE_CLEAR_SEARCH): New button resource ID. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com clear_search.patch Description: clear_search.patch
src/winsup/cygwin ChangeLog include/sys/select.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-05-08 10:54:58 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include/sys: select.h Log message: * include/sys/select.h: Guard definitions with __USE_W32_SOCKETS as the accompanying fd_set definitions in newlib's sys/types.h. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4478r2=1.4479 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/select.h.diff?cvsroot=srcr1=1.3r2=1.4
src/winsup/cygwin ChangeLog strfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-05-08 19:38:33 Modified files: winsup/cygwin : ChangeLog strfuncs.cc Log message: * strfuncs.cc (sys_cp_wcstombs): Set errno to 0 before converting wide char to SO/UTF-8 sequence. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4479r2=1.4480 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strfuncs.cc.diff?cvsroot=srcr1=1.25r2=1.26
src/winsup/cygwin ChangeLog strfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-05-08 20:28:20 Modified files: winsup/cygwin : ChangeLog strfuncs.cc Log message: * strfuncs.cc (sys_cp_wcstombs): save and restore previous errno value. (sys_cp_mbstowcs): Ditto. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4480r2=1.4481 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strfuncs.cc.diff?cvsroot=srcr1=1.26r2=1.27
Re: popup consoles on Windows 7
On Apr 21 18:00, Corinna Vinschen wrote:
On Apr 21 16:35, Andy Koppe wrote:
2009/4/16 Corinna Vinschen:
int
main(void)
{
HWINSTA wst = CreateWindowStation (0, 0, WINSTA_ALL_ACCESS, 0);
SetProcessWindowStation(wst);
AllocConsole();
Sleep(3000);
return 0;
}
There seems to have been quite a bit of rearchitecting in this area.
On 7 there's a process called 'conhost.exe' for every console, which I
don't think I've seen on previous Windows versions.
Confirmed. I'm going to send a bug report to MSFT.
Thanks! Is there a way to monitor developments on this issue?
If you have a connect account and are participating officially in the W7
testing, then yes. Otherwise I fear this is sort of a closed group.
I only got one reply from MSFT so far. The issue has been forwarded to
the WindowStation/Desktop group. If I get another reply I'll keep you
informed.
Unfortunately I got the reply that this issue cannot be addressed this
time but MSFT will consider addressing the issue in a future version of
Windows.
This is really bad. I'm still trying to convince them that a fix is
really important, but history is against me. I'm going to try to get
at least a workaround.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: base-files (was: [1.7] Updated: cygwin-1.7.0-47)
Hi John,
On May 6 16:33, Corinna Vinschen wrote:
On May 6 14:54, John Morrison wrote:
On Wed, May 6, 2009 2:25 pm, Corinna Vinschen wrote:
I just uploaded a new Cygwin 1.7 test release, 1.7.0-47.
What's new in contrast to 1.7.0-46
===
- Never use HOMEDRIVE/HOMEPATH to construct a default home directory for
the current user. The mechanism to evaluate the pathname is now:
- If $HOME is already set in the envirnment, use it.
- Otherwise, if /etc/passwd contains a non-empty homedir for the
current user, use it.
- Otherwise, default to /home/USERNAME.
This circumvents a few installation problems and decouples the Cygwin
homedir by default from the Windows profile directory, which
especially starting with Vista results in performance problems due to
the new Explorer behaviour concerning shared files. If you want to
use the Windows profile dir as home dir, set $HOME or tweak your
/etc/passwd entry accordingly.
I'll change /etc/profile to reflect the above text.
Could this result in situations where the skel files arn't copied?
Yes, that was one of the reasons I changed it. The old way to eval the
user's HOME dir could result in the skel files not being created because
the HOME directory already existed. The non-existance of HOME triggers
writing the skel files. Now the skel files typically are created
because /home/$USER doesn't exist when bash is started the first time.
after a short discussion on cygwin-developers starting here
http://cygwin.com/ml/cygwin-developers/2009-05/msg1.html
I'm wondering if it wouldn't be better to default directly to /
if the user's home dir can't be created or accessed. It would
also just simplify /etc/profile:
--- profile.ORIG2009-05-08 11:28:55.456869200 +0200
+++ profile 2009-05-08 11:31:41.174558600 +0200
@@ -64,12 +64,7 @@ if [ ! -d ${HOME} ]; then
done
else
echo ${HOME} could not be created.
-
- { [ -d ${TEMP} ] HOME=${TEMP}; } ||
- { [ -d ${TMP} ] HOME=${TMP}; } ||
- { [ -d /tmp ] HOME=/tmp; } ||
- HOME=/
-
+ HOME=/
echo Setting HOME to ${HOME}.
fi
fi
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
2 questions about fonts
I've a great many postscript fonts installed under Windows XP--- is there a way to acquaint cygwin of these? How are font names resolved for lpr? For instance in a non cygwin situation, I might have a line in a postscript file such as: /BriemMono findfont 8 scalefont setfont (typeset these words) show. This runs without problems, I'd like to be able to do something similar using cygwin (obviously using cygwin installed fonts). I am somewhat clueless here, hence these questions. Thanks for any help... --hsm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: base-files (was: [1.7] Updated: cygwin-1.7.0-47)
On Fri, May 8, 2009 10:32 am, Corinna Vinschen wrote:
Hi John,
On May 6 16:33, Corinna Vinschen wrote:
On May 6 14:54, John Morrison wrote:
On Wed, May 6, 2009 2:25 pm, Corinna Vinschen wrote:
I just uploaded a new Cygwin 1.7 test release, 1.7.0-47.
What's new in contrast to 1.7.0-46
===
- Never use HOMEDRIVE/HOMEPATH to construct a default home directory
for
the current user. The mechanism to evaluate the pathname is now:
- If $HOME is already set in the envirnment, use it.
- Otherwise, if /etc/passwd contains a non-empty homedir for the
current user, use it.
- Otherwise, default to /home/USERNAME.
This circumvents a few installation problems and decouples the
Cygwin
homedir by default from the Windows profile directory, which
especially starting with Vista results in performance problems due
to
the new Explorer behaviour concerning shared files. If you want
to
use the Windows profile dir as home dir, set $HOME or tweak your
/etc/passwd entry accordingly.
I'll change /etc/profile to reflect the above text.
Could this result in situations where the skel files arn't copied?
Yes, that was one of the reasons I changed it. The old way to eval the
user's HOME dir could result in the skel files not being created because
the HOME directory already existed. The non-existance of HOME triggers
writing the skel files. Now the skel files typically are created
because /home/$USER doesn't exist when bash is started the first time.
after a short discussion on cygwin-developers starting here
http://cygwin.com/ml/cygwin-developers/2009-05/msg1.html
I'm wondering if it wouldn't be better to default directly to /
if the user's home dir can't be created or accessed. It would
also just simplify /etc/profile:
--- profile.ORIG2009-05-08 11:28:55.456869200 +0200
+++ profile 2009-05-08 11:31:41.174558600 +0200
@@ -64,12 +64,7 @@ if [ ! -d ${HOME} ]; then
done
else
echo ${HOME} could not be created.
-
- { [ -d ${TEMP} ] HOME=${TEMP}; } ||
- { [ -d ${TMP} ] HOME=${TMP}; } ||
- { [ -d /tmp ] HOME=/tmp; } ||
- HOME=/
-
+ HOME=/
echo Setting HOME to ${HOME}.
fi
fi
OK, I'll also move the umask setting above the creation of home (there was
comment in the thread). I don't follow the -developer list. Would it be
worth me subscribing?
J.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: base-files (was: [1.7] Updated: cygwin-1.7.0-47)
On May 8 10:53, John Morrison wrote:
On Fri, May 8, 2009 10:32 am, Corinna Vinschen wrote:
Yes, that was one of the reasons I changed it. The old way to eval the
user's HOME dir could result in the skel files not being created because
the HOME directory already existed. The non-existance of HOME triggers
writing the skel files. Now the skel files typically are created
because /home/$USER doesn't exist when bash is started the first time.
after a short discussion on cygwin-developers starting here
http://cygwin.com/ml/cygwin-developers/2009-05/msg1.html
I'm wondering if it wouldn't be better to default directly to /
if the user's home dir can't be created or accessed. It would
also just simplify /etc/profile:
--- profile.ORIG2009-05-08 11:28:55.456869200 +0200
+++ profile 2009-05-08 11:31:41.174558600 +0200
@@ -64,12 +64,7 @@ if [ ! -d ${HOME} ]; then
done
else
echo ${HOME} could not be created.
-
- { [ -d ${TEMP} ] HOME=${TEMP}; } ||
- { [ -d ${TMP} ] HOME=${TMP}; } ||
- { [ -d /tmp ] HOME=/tmp; } ||
- HOME=/
-
+ HOME=/
echo Setting HOME to ${HOME}.
fi
fi
OK, I'll also move the umask setting above the creation of home (there was
comment in the thread). I don't follow the -developer list. Would it be
worth me subscribing?
The umask change isn't actually necessary since Cygwin sets it by
default to 0022 now. But it doesn't hurt either. I guess it's
even cleaner to do that.
As for cygwin-developers, you really don't have to subscribe. I don't
think it's worth to subscribe for non-developers. It's very low volume
and if something crops up it makes its way to the cygwin or cygwin-apps
list anyway.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[OT] Avoiding symlinks when launching cygwin apps from win32 apps [was Re: [1.5][gcc-3.4.4] python-2.5.4 distutils failed to compile c files]
[ Subject changed, and OT tagged because this is really becoming about windows command shell programming techniques. ] Joe Pham wrote: Dave Korn writes: What about calling distutils.Ccompiler.set_executables() in your script that invokes distutils? I probably could, but I'd have to do that for each and every package that I need to build. Well, there's always the Windows-way-of-interposing-by-symlink: put a .bat file in your %PATH% ahead of or even alongside the executable. If you just invoke gcc, and there's a gcc.bat and a gcc.exe (which happens to be a non-executable symlink, but let that pass for now) both in the same directory in PATH, the .bat file will win. And can then invoke the actual (differently-named) exe passing through all the command-line args. To prevent the .bat from interfering with normal Cygwin operation, I'd recommend you add an extra (new) directory to the front of your windows PATH and put the .bat file(s) there, rather than shoving them alongside in /bin. (Aren't you going to have hideous nightmares in this whole thing anyway when windows python passes windows-style paths to cygwin gcc? Well, it should mostly work, but don't expect to get anything useful if you're generating dependency files.) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7][python] File operation API to multibyte filenames fails.
Hi. File operation API to multibyte filenames fails on Python and Cygwin-1.7. Which Python or Cygwin-1.7 should be fixed? My environment: Windows XP SP3, Cygwin-1.7.0-46, and LANG=ja_JP.UTF-8 The following code fails on the directory which has multibyte filenames: import os os.listdir(.) Traceback (most recent call last): File stdin, line 1, in module OSError: [Errno 138] Invalid or incomplete multibyte or wide character: '.' The following code works correctly: import os import locale locale.setlocale(locale.LC_CTYPE, '') 'ja_JP.UTF-8' os.listdir(.) [(snip), '\xe3\x82\xb9\xe3\x82\xbf\xe3\x83\xbc\xe3\x83\x88 \xe3\x83\xa1\xe3\x83\x8b\xe3\x83\xa5\xe3\x83\xbc', '\xe3\x83\x87\xe3\x82\xb9\xe3\x82\xaf\xe3\x83\x88\xe3\x83\x83\xe3\x83\x97'] However, it is impossible to fix all the python scripts. There are two causes. - Python has intentionally evaded the execution of setlocale(LC_ALL, ) and/or setlocale(LC_CTYPE, ). - When locale is not appropriately set, Cygwin-1.7 converts non-ASCII character into a special sequence. (see Convert chars invalid in the current codepage to a sequence ASCII SO part of sys_cp_wcstombs in winsup/cygwin/strfuncs.cc) Which Python or Cygwin-1.7 should be fixed? -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
On May 8 22:02, IWAMURO Motonori wrote: Hi. File operation API to multibyte filenames fails on Python and Cygwin-1.7. Which Python or Cygwin-1.7 should be fixed? My environment: Windows XP SP3, Cygwin-1.7.0-46, and LANG=ja_JP.UTF-8 The following code fails on the directory which has multibyte filenames: import os os.listdir(.) Traceback (most recent call last): File stdin, line 1, in module OSError: [Errno 138] Invalid or incomplete multibyte or wide character: '.' The following code works correctly: import os import locale locale.setlocale(locale.LC_CTYPE, '') 'ja_JP.UTF-8' os.listdir(.) [(snip), '\xe3\x82\xb9\xe3\x82\xbf\xe3\x83\xbc\xe3\x83\x88 \xe3\x83\xa1\xe3\x83\x8b\xe3\x83\xa5\xe3\x83\xbc', '\xe3\x83\x87\xe3\x82\xb9\xe3\x82\xaf\xe3\x83\x88\xe3\x83\x83\xe3\x83\x97'] However, it is impossible to fix all the python scripts. There are two causes. - Python has intentionally evaded the execution of setlocale(LC_ALL, ) and/or setlocale(LC_CTYPE, ). - When locale is not appropriately set, Cygwin-1.7 converts non-ASCII character into a special sequence. (see Convert chars invalid in the current codepage to a sequence ASCII SO part of sys_cp_wcstombs in winsup/cygwin/strfuncs.cc) Which Python or Cygwin-1.7 should be fixed? Your scripts. Python correctly doesn't use setlocale because it's the responsibility of the application to set the local if it uses non-ASCII chars. And Cygwin simply has no chance to convert UTF-8 to UTF-16 if the application doesn't ask for UTF-8. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
Hi. 2009/5/8 Corinna Vinschen corinna-cyg...@cygwin.com: Your scripts. Python correctly doesn't use setlocale because it's the responsibility of the application to set the local if it uses non-ASCII chars. And Cygwin simply has no chance to convert UTF-8 to UTF-16 if the application doesn't ask for UTF-8. Oh, it is very very difficult. Because ALL python utilities which access files or directories fail. For example, Mercurial doesn't work. hg stat abort: Invalid or incomplete multibyte or wide character: /home/iwa -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
print on cygwin command window with gfortran?
I use gfortran on cygwin and i want to print in the command window (like it prints in windows) i use the usual stuff: WRITE(6,*) 'Give a number:' or PRINT(6,*) 'Give a number:' but the execution completes without any printing.. What is wrong? -- View this message in context: http://www.nabble.com/print-on-cygwin-command-window-with-gfortran--tp23447933p23447933.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
R: print on cygwin command window with gfortran?
--- Ven 8/5/09, Gus K ha scritto: Da: Gus K Oggetto: print on cygwin command window with gfortran? A: cygwin Data: Venerdì 8 maggio 2009, 17:13 I use gfortran on cygwin and i want to print in the command window (like it prints in windows) i use the usual stuff: WRITE(6,*) 'Give a number:' or PRINT(6,*) 'Give a number:' but the execution completes without any printing.. What is wrong? eventually gfortran We have already found a similar issue with output redirection http://thread.gmane.org/gmane.os.cygwin/104875/focus=104928 Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.25 missing gtkrecentmanager.h
I installed cygwin to build a GTK2 program and was able to build a test program but was unable to build my application. I installed all gtk packages as well as some dependencies that were not automatically selected (atk and cairo) as well as all the X11 files and autotools. I was able to run autoconf and configure without modification (very impressive) but when I tried to make I found that gtkRecentManager was not defined. In fact it seemed that gtkrecentmanager.h was missing from /usr/include/gtk-2.0/gtk along with 30 other files (208 files on my unix box, 178 in cygwin.) Any ideas what might have caused this? Thank you for your time, Soren Berg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
On May 8 22:21, IWAMURO Motonori wrote:
Hi.
2009/5/8 Corinna Vinschen corinna-cyg...@cygwin.com:
Your scripts. Python correctly doesn't use setlocale because it's
the responsibility of the application to set the local if it uses
non-ASCII chars. And Cygwin simply has no chance to convert UTF-8
to UTF-16 if the application doesn't ask for UTF-8.
Oh, it is very very difficult.
Because ALL python utilities which access files or directories fail.
For example, Mercurial doesn't work.
I can reproduce this issue and I created a simple application to
create your example filenames in the current dir (see below).
Given the python testcase
import os
os.listdir(.)
can't see a fault in Cygwin. Neither from strace, nor in a GDB session.
The readdir calls return the filenames using the SO sequences so that
a valid byte-stream is created which also works in the C locale.
However, for some reason there's a EILSEQ (138) errno generated, but
from what I can tell it's not generated in Cygwin or newlib code.
So I'd like to ask Jason, our python maintainer, to have a look into
that. Maybe we just need a python rebuild for 1.7?
Corinna
This is the simple code I used to create the japanese filenames:
#include fcntl.h
#include locale.h
int main ()
{
char file1[] = { 0xe3, 0x82, 0xb9, 0xe3, 0x82, 0xbf, 0xe3, 0x83, 0xbc,
0xe3, 0x83, 0x88, 0xe3, 0x83, 0xa1, 0xe3, 0x83, 0x8b,
0xe3, 0x83, 0xa5, 0xe3, 0x83, 0xbc, 0 };
char file2[] = { 0xe3, 0x83, 0x87, 0xe3, 0x82, 0xb9, 0xe3, 0x82, 0xaf,
0xe3, 0x83, 0x88, 0xe3, 0x83, 0x83, 0xe3, 0x83, 0x97, 0 };
setlocale (LC_ALL, en_US.UTF-8);
int fd = open (file1, O_CREAT|O_RDWR, 0644);
close (fd);
fd = open (file2, O_CREAT|O_RDWR, 0644);
close (fd);
return 0;
}
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.25: Intermittent hangs or network issues
Larry Hall (Cygwin) wrote: Jim Marshall wrote: Jim Marshall wrote: Dave Korn wrote: Jim Marshall wrote: I do not have any firewall software running, Potential app conflicts: ZoneAlarm Personal Firewall Detected: HKLM Registry Key, Named file. Do you possibly suffer from the Cisco VPN client software that comes with a built-in version of the core ZA firewall component? cheers, DaveK Hi Dave et al, I removed the cisco VPN, but I am still seeing the hangs. Also I guess I spoke too soon about other apps not hanging as I have noticed xemacs and xterm hanging when starting (the GUI doesn't open but ctrl-c works to quit them from the terminal I started them from) - it is also happens far less often then ssh and cvs. I've attached a new cygcheck, I know it still says that the zone alarm entry is still present but I don't know of any app that is using it and I don't see any processes running, so I am a bit of a loss as to why that is there. Thanks again Maybe a short output file from strace would help point a finger. And maybe not. ;-) Finally got around to doing the strace... $ strace ssh myt...@mythtv ** Program name: C:\cygwin\bin\ssh.exe (pid 6028, ppid 1) App version: 1005.25, api: 0.156 DLL version: 1005.25, api: 0.156 DLL build:2008-06-12 19:34 OS version: Windows NT-5.1 Heap size:402653184 Date/Time:2009-05-08 13:17:17 ** stuff removed 2179 275368 [main] ssh 6028 wsock_init: res 0 42 275410 [main] ssh 6028 wsock_init: wVersion 514 32 275442 [main] ssh 6028 wsock_init: wHighVersion 514 31 275473 [main] ssh 6028 wsock_init: szDescription WinSock 2.0 30 275503 [main] ssh 6028 wsock_init: szSystemStatus Running 30 275533 [main] ssh 6028 wsock_init: iMaxSockets 0 30 275563 [main] ssh 6028 wsock_init: iMaxUdpDg 0 30 275593 [main] ssh 6028 wsock_init: lpVendorInfo 0 6733 282326 [main] ssh 6028 __set_errno: void __set_winsock_errno(const char*, int):234 val 1 382 282708 [main] ssh 6028 __set_winsock_errno: __dup_ent:334 - winsock error 11004 - errno 1 36 282744 [main] ssh 6028 cygwin_getservbyname: 0x0 = getservbyname (ssh, tcp) 49 282793 [main] ssh 6028 sig_send: sendsig 0x6E8, pid 6028, signal -34, its_me 1 32 282825 [main] ssh 6028 sig_send: wakeup 0x6B0 31 282856 [main] ssh 6028 sig_send: Waiting for pack.wakeup 0x6B0 799 283655 [sig] ssh 6028 wait_sig: signalling pack.wakeup 0x6B0 723 284378 [main] ssh 6028 sig_send: returning 0x0 from sending signal -34 560 284938 [main] ssh 6028 __dup_ent: duping hostent mythtv, 0x18BA6CA0 90 285028 [main] ssh 6028 __dup_ent: duped hostent mythtv, 0x6ACCC8 38 285066 [main] ssh 6028 cygwin_gethostbyname: h_name mythtv 1032 286098 [main] ssh 6028 cygwin_socket: socket (2, 1, 0) 5937 292035 [main] ssh 6028 fdsock: reset socket inheritance 126 292161 [main] ssh 6028 build_fh_pc: fh 0x61169E50 104 292265 [main] ssh 6028 fhandler_base::set_flags: flags 0x10002, supplied_bin 0x0 124 292389 [main] ssh 6028 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 385 292774 [main] ssh 6028 fhandler_base::set_flags: filemode set to binary 290 293064 [main] ssh 6028 fdsock: fd 3, name '', soc 0x6B4 514 293578 [main] ssh 6028 cygwin_socket: 3 = socket (2, 1, 0) 1223 294801 [main] ssh 6028 sig_send: sendsig 0x6E8, pid 6028, signal -34, its_me 1 60 294861 [main] ssh 6028 sig_send: wakeup 0x69C 34 294895 [main] ssh 6028 sig_send: Waiting for pack.wakeup 0x69C 305 295200 [sig] ssh 6028 wait_sig: signalling pack.wakeup 0x69C 51 295251 [main] ssh 6028 sig_send: returning 0x0 from sending signal -34 72 295323 [main] ssh 6028 fhandler_socket::ioctl: socket is now nonblocking 39 295362 [main] ssh 6028 fhandler_socket::ioctl: 0 = ioctl_socket (8004667E, 23B80C) 979 296341 [main] ssh 6028 __set_errno: void __set_winsock_errno(const char*, int):234 val 119 50 296391 [main] ssh 6028 __set_winsock_errno: connect:788 - winsock error 10036 - errno 119 44 296435 [main] ssh 6028 cygwin_select: 4, 0x0, 0x23B7C0, 0x23B7A0, 0x0 88 296523 [main] ssh 6028 dtable::select_write: fd 3 43 296566 [main] ssh 6028 dtable::select_except: fd 3 51 296617 [main] ssh 6028 cygwin_select: to NULL, ms 43 296660 [main] ssh 6028 cygwin_select: sel.always_ready 0 74 296734 [main] ssh 6028 start_thread_socket: Handle 0x6B4 38 296772 [main] ssh 6028 start_thread_socket: Added to writefds 40 296812 [main] ssh 6028 start_thread_socket: Added to exceptfds 2983 299795 [main] ssh 6028 start_thread_socket: opened new socket 0x688 52 299847 [main] ssh 6028 start_thread_socket: exitsock 0x688 41 299888 [main] ssh 6028 start_thread_socket: stuff_start 0x23B724 308 300196 [select_socket] ssh 6028 cygthread::stub: thread 'select_socket', id 0x17B4, stack_ptr 0x190ACDC0 49 300245
[ANNOUNCEMENT] [1.7] Updated: cpio-2.9.90-5
I've just updated the version of cpio to 2.9.90-5. This is a new Cygwin 1.7 version of cpio which is 100% source code equivalent to the cpio-2.9.90-5 version for Fedora 11. This release should fix the problem reported in http://cygwin.com/ml/cygwin/2009-04/msg00600.html It also comes with a full man page rather than a man page which just refers to the info page. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
2009/5/9 Corinna Vinschen corinna-cyg...@cygwin.com:
can't see a fault in Cygwin. Neither from strace, nor in a GDB session.
The readdir calls return the filenames using the SO sequences so that
a valid byte-stream is created which also works in the C locale.
However, for some reason there's a EILSEQ (138) errno generated, but
from what I can tell it's not generated in Cygwin or newlib code.
I think that I found Cygwin-1.7's bug.
int bytes = f_wctomb (_REENT, buf, pw, charset, ps);
f_wctomb is __ascii_wctomb when not using setlocale(LC_CTYPE).
If return value of __ascii_wctomb == -1, errno == EILSEQ.
I think that it is necessary to reset errno after wctomb.
--- a/winsup/cygwin/strfuncs.cc Thu May 07 12:29:17 2009 +0900
+++ b/winsup/cygwin/strfuncs.cc Sat May 09 04:01:33 2009 +0900
@@ -432,6 +432,7 @@
ASCII SO; UTF-8 representation of invalid char. */
if (bytes == -1 *charset != 'U'/*TF-8*/)
{
+ errno = 0;
buf[0] = 0x0e; /* ASCII SO */
bytes = __utf8_wctomb (_REENT, buf + 1, pw, charset, ps);
if (bytes == -1)
[test code]
#include stdio.h
#include dirent.h
#include errno.h
int main(void) {
DIR *dir;
struct dirent *ent;
dir = opendir(.);
while ((ent = readdir(dir)) != NULL)
printf(%d\n, ent-d_name, errno);
printf(%d\n, errno);
closedir(dir);
return 0;
}
[result 1.7.0-47]
0
0
138
138
138
[result applied above patch]
0
0
0
0
0
--
IWAMURO Motnori http://vmi.jp/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
Sorry, test code is bad. - printf(%d\n, ent-d_name, errno); + printf(%d\n, errno); -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
On May 9 04:21, IWAMURO Motonori wrote:
2009/5/9 Corinna Vinschen corinna-cyg...@cygwin.com:
can't see a fault in Cygwin. Neither from strace, nor in a GDB session.
The readdir calls return the filenames using the SO sequences so that
a valid byte-stream is created which also works in the C locale.
However, for some reason there's a EILSEQ (138) errno generated, but
from what I can tell it's not generated in Cygwin or newlib code.
I think that I found Cygwin-1.7's bug.
int bytes = f_wctomb (_REENT, buf, pw, charset, ps);
f_wctomb is __ascii_wctomb when not using setlocale(LC_CTYPE).
If return value of __ascii_wctomb == -1, errno == EILSEQ.
I think that it is necessary to reset errno after wctomb.
--- a/winsup/cygwin/strfuncs.cc Thu May 07 12:29:17 2009 +0900
+++ b/winsup/cygwin/strfuncs.cc Sat May 09 04:01:33 2009 +0900
@@ -432,6 +432,7 @@
ASCII SO; UTF-8 representation of invalid char. */
if (bytes == -1 *charset != 'U'/*TF-8*/)
{
+ errno = 0;
buf[0] = 0x0e; /* ASCII SO */
bytes = __utf8_wctomb (_REENT, buf + 1, pw, charset, ps);
if (bytes == -1)
Cool. Thanks for the patch. This actually solves the problem.
I applied the patch with just a little tweak.
Nevertheless, it looks like python has a problem as well. Why does it
check an errno if the functions returned successfully? That doesn't
sound right to me.
Thanks again,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
2009/5/9 Corinna Vinschen corinna-cyg...@cygwin.com: Cool. Thanks for the patch. This actually solves the problem. I applied the patch with just a little tweak. Thanks. The following patch might be better. --- a/winsup/cygwin/strfuncs.cc Thu May 07 12:29:17 2009 +0900 +++ b/winsup/cygwin/strfuncs.cc Sat May 09 04:39:49 2009 +0900 @@ -427,7 +427,9 @@ path names) is transform_chars in path.cc. */ if ((pw 0xff00) == 0xf000) pw = 0xff; + int eno = errno; int bytes = f_wctomb (_REENT, buf, pw, charset, ps); + errno = eno; /* Convert chars invalid in the current codepage to a sequence ASCII SO; UTF-8 representation of invalid char. */ if (bytes == -1 *charset != 'U'/*TF-8*/) Nevertheless, it looks like python has a problem as well. Why does it check an errno if the functions returned successfully? That doesn't sound right to me. When the last readdir returns NULL, python detects the error because readdir keeps previous errno. 1) ep = readdir(dirp); // ep-d_name == ., errno == 0 Python check only ep != NULL. - OK 2) ep = readdir(dirp); // ep-d_name == .., errno == 0 Python check only ep != NULL. - OK 3) ep = readdir(dirp); // ep-d_name == \xe3\x82..., errno == 138 Python check only ep != NULL. - OK 4) ep = readdir(dirp); // ep-d_name == \xe3\x83..., errno == 138 Python check only ep != NULL. - OK 5) ep = readdir(dirp); // ep == NULL, errno == 138 Python check ep == NULL and errno != 0. - Fail! -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
On May 9 05:02, IWAMURO Motonori wrote: 2009/5/9 Corinna Vinschen corinna-cyg...@cygwin.com: Cool. Thanks for the patch. This actually solves the problem. I applied the patch with just a little tweak. Thanks. The following patch might be better. --- a/winsup/cygwin/strfuncs.cc Thu May 07 12:29:17 2009 +0900 +++ b/winsup/cygwin/strfuncs.cc Sat May 09 04:39:49 2009 +0900 @@ -427,7 +427,9 @@ path names) is transform_chars in path.cc. */ if ((pw 0xff00) == 0xf000) pw = 0xff; + int eno = errno; int bytes = f_wctomb (_REENT, buf, pw, charset, ps); + errno = eno; /* Convert chars invalid in the current codepage to a sequence ASCII SO; UTF-8 representation of invalid char. */ if (bytes == -1 *charset != 'U'/*TF-8*/) Thanks. I implemented that differently by just storing and restoring the errno value at function entry and exit. The sys_wcstombs and sys_mbstowcs functions are not supposed to set errno anyway. Nevertheless, it looks like python has a problem as well. Why does it check an errno if the functions returned successfully? That doesn't sound right to me. When the last readdir returns NULL, python detects the error because readdir keeps previous errno. 1) ep = readdir(dirp); // ep-d_name == ., errno == 0 Python check only ep != NULL. - OK 2) ep = readdir(dirp); // ep-d_name == .., errno == 0 Python check only ep != NULL. - OK 3) ep = readdir(dirp); // ep-d_name == \xe3\x82..., errno == 138 Python check only ep != NULL. - OK 4) ep = readdir(dirp); // ep-d_name == \xe3\x83..., errno == 138 Python check only ep != NULL. - OK 5) ep = readdir(dirp); // ep == NULL, errno == 138 Python check ep == NULL and errno != 0. - Fail! Ouch, right. It shows that I'm tired. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7][python] File operation API to multibyte filenames fails.
Corinna Vinschen wrote: On May 9 05:02, IWAMURO Motonori wrote: When the last readdir returns NULL, python detects the error because readdir keeps previous errno. 1) ep = readdir(dirp); // ep-d_name == ., errno == 0 Python check only ep != NULL. - OK 2) ep = readdir(dirp); // ep-d_name == .., errno == 0 Python check only ep != NULL. - OK 3) ep = readdir(dirp); // ep-d_name == \xe3\x82..., errno == 138 Python check only ep != NULL. - OK 4) ep = readdir(dirp); // ep-d_name == \xe3\x83..., errno == 138 Python check only ep != NULL. - OK 5) ep = readdir(dirp); // ep == NULL, errno == 138 Python check ep == NULL and errno != 0. - Fail! Ouch, right. It shows that I'm tired. It shows that python is buggy then. It should be resetting errno itself before calling readdir, so that it can distinguish between the EOF and error conditions. http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html Upon successful completion, readdir() shall return a pointer to an object of type struct dirent. When an error is encountered, a null pointer shall be returned and errno shall be set to indicate the error. When the end of the directory is encountered, a null pointer shall be returned and errno is not changed. ... note particularly the not changed. Or perhaps python should test feof/ferror before deciding whether to inspect errno, but either way it shouldn't just assume that because readdir returns NULL that implies errno is valid. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin programs doesn't support non-ASCII filenames
(My system locale is zh_CN) 1, test path set LANG= cygpath -am . C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK cygpath -am . C:/Profiles/Shecti/桌面 set LANG=C cygpath -am . C:/Profiles/Shecti/×ÀÃæ 2, the `test' utility set LANG= bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GB2312 bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi ok C:/Profiles/Shecti/桌面 set LANG=C bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D;else echo fail $D; fi fail C:/Profiles/Shecti/×ÀÃæ 3, the `cp' utility set LANG= bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/桌面/a.zip': No such file or directory fail set LANG=zh_CN.GB2312 bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/桌面/a.zip': No such file or directory fail set LANG=zh_CN.GBK bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi ok set LANG=C bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/×ÀÃæ/a.zip': No such file or directory fail 4, the `d' utility set LANG= bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GB2312 bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=C bash -c D=$(cygpath -am .); if d $D; then echo ok $D; elseecho fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/×ÀÃæ doesn't exist! fail C:/Profiles/Shecti/×ÀÃæ Problems: (1) Executables `test', `cp' (and rm, cat, stat, find, etc. seems like all of binutils) supports locale settings, while `d' (and gcc, zip, unzip, gzip, gunzip, jar, vi, etc. not of binutils) are not. (2) Even programs of binutils may not support locale settings correctly, The GB2312 charset is a subset of GBK charset, and the characters ` 桌面' is included in GB2312 charset. So in this example, GB2312 SHOULD WORK. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug: Cygwin won't export environ vars to win32 programs, when the current work dir contains non-ascii characters.
On 2009-5-4 16:43, Corinna Vinschen wrote: On Apr 29 16:20, Lenik wrote: (Following example is based on bash, but the same to ash, tcsh, ksh, etc., so this should be bug of cygwin.) [...] (2) With Chinese characters, most variables are lost: C:\Profiles\Shecti\??bash -c cmd /c set COMSPEC=C:\WINDOWS\system32\cmd.exe PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS PROMPT=$P$G C:\Profiles\Shecti\?? [...] cygwin1.dll v0.0 ts=2009/1/27 23:49 Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 192 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Tue Jan 27 16:49:28 CET 2009 Shared id: cygwin1S5 Try with the latest Cygwin 1.7 DLL. Yours from January still has a bug which results in a broken environment when using native chars in environment variables. This bug has been fixed in 1.7.0-46. Corinna It works. (1.7.0-47) Thank you -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] Updated: cpio-2.9.90-5
I've just updated the version of cpio to 2.9.90-5. This is a new Cygwin 1.7 version of cpio which is 100% source code equivalent to the cpio-2.9.90-5 version for Fedora 11. This release should fix the problem reported in http://cygwin.com/ml/cygwin/2009-04/msg00600.html It also comes with a full man page rather than a man page which just refers to the info page. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cyg...@cygwin.com Red Hat, Inc.
