Re: XRaiseWindow for activating windows in multiwindow mode
I am a bit late but I will be happy to test this version of XWin. Could you give me a patched binary version please ? Regards, 2011/9/4 Oliver Schmidt oschmidt-mailingli...@gmx.de It's me again ;-) On 9/3/2011 9:01 PM, Jon TURNEY wrote: As discussed in the thread [2] various scenarios, e.g. AOT windows, native windows interleaved with X windows in the native Z order, Windows with focus-follows-mouse enabled via TweakUI all need testing after trying to fix this, to ensure you haven't regressed them. [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html I'm not sure if I'm correctly reproducing the above usage scenario always on top, but I did the following under Windows 7 and XP: 1) downloaded and installed http://www.abstractpath.com/powermenu/ 2) launched a xclock or a native Windows program (e.g. Internet Explorer) and select Always on top with right mouse click on the window's titel bar 3) programmatically launched and raised other x top level windows 4) Everything works: the checked windows stay top level, the programmatically raised windows became top level amongst all other non always top level windows and get keyboard focus and activated window frame. I was also able to minimize and restore the always on top window without any problems. Moreover the redraw windows while moving and sizing hack http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html does also work with the always on top feature enabled for the foreground and background window. Also mixtures of cygwin x server windows with native Windows applications all with always on top feature enabled are working. What is not working: Clicking on minimize to tray on a cygwin x server window that has also the always on top feature: this causes the window frame to vanish, but the window content is still redrawn by the xserver on the underlaying x11 window. This is difficult to describe, but this does also not work with the official unpatched cygwin x server 1.10.3-1. This minimize-to-tray effect for always on top windows is also described here: http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html So according to my tests the patch does not introduce new misbehaviour regarding powermenu's always on top window feature. I could provide a patched binary XWin.exe, if someone wants to do more testing... Best regards, Oliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server shortcut removed from start menu?
On 18/10/2011 19:58, Ryan Johnson wrote: I recently upgraded to the latest cygwin/x and my start menu no longer contains a shortcut to start the x-server -- the thing there is a shortcut for xterm. Is there a packaging change that I wasn't aware of or is this a bug? This should not have changed. Those start menu links should have been created when the xinit package is installed, by the /etc/postinstall/xinit.sh script. You might want to take a look at /var/log/setup.log and see if that script ran successfully. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server shortcut removed from start menu?
On 19/10/2011 7:43 AM, Jon TURNEY wrote: On 18/10/2011 19:58, Ryan Johnson wrote: I recently upgraded to the latest cygwin/x and my start menu no longer contains a shortcut to start the x-server -- the thing there is a shortcut for xterm. Is there a packaging change that I wasn't aware of or is this a bug? This should not have changed. Those start menu links should have been created when the xinit package is installed, by the /etc/postinstall/xinit.sh script. You might want to take a look at /var/log/setup.log and see if that script ran successfully. Heh. The postinstall/xinit.sh script has failed to run every time I've run setup.exe in the last 9 months. 2011/10/18 14:57:13 Running preremove script for X-start-menu-icons 2011/10/18 14:57:13 running: c:\cygwin\bin\bash.exe --norc --noprofile /etc/preremove/X-start-menu-icons.sh 2011/10/18 14:57:14 Uninstalling X-start-menu-icons 2011/10/18 14:57:14 Extracting from file://C:\Users\Ryan\Downloads\cygwin/http%3a%2f%2fmirror.csclub.uwaterloo.ca%2fcygwin%2f/release/X11/X-start-menu-icons/X-start-menu-icons-1.0.4-1.tar.bz2 2011/10/18 14:57:14 Changing gid back to original 2011/10/18 14:57:14 running: c:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/X-start-menu-icons.sh 2011/10/18 14:57:17 running: c:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/xinit.sh 2011/10/18 14:57:17 abnormal exit: exit code=3 I guess something different than usual went wrong? What's the best way to debug it? Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server shortcut removed from start menu?
On 19/10/2011 12:55, Ryan Johnson wrote: 2011/10/18 14:57:17 running: c:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/xinit.sh 2011/10/18 14:57:17 abnormal exit: exit code=3 I guess something different than usual went wrong? What's the best way to debug it? The full output of the shell commands for the most recent run of setup can be found in /var/log/setup.log.full You might also try to run that bash command manually (perhaps with an additional -x after --noprofile) and see what's going wrong? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server shortcut removed from start menu?
On 19/10/2011 9:40 AM, Jon TURNEY wrote: On 19/10/2011 12:55, Ryan Johnson wrote: 2011/10/18 14:57:17 running: c:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/xinit.sh 2011/10/18 14:57:17 abnormal exit: exit code=3 I guess something different than usual went wrong? What's the best way to debug it? The full output of the shell commands for the most recent run of setup can be found in /var/log/setup.log.full You might also try to run that bash command manually (perhaps with an additional -x after --noprofile) and see what's going wrong? This looks like the culprit: mkshortcut: Saving C:\ProgramData\Microsoft\Windows\Start Menu\Programs\C:\cygwin\Cygwin-X\XWin Server.lnk failed; does the target directory exist? Missing $(basename ...)? I tried peeking inside the .sh files but they're greek to me. Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
X won't start anymore
Hello, I guess it happened after some MS update but I can't start X anymore (from an rxvt-native console since clicking the desktop icon doesn't display anything): $ startxwin.exe Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.11.1.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.11.1-1 built 2011-10-05 XWin was started with the following command line: X :0 -multiwindow (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/bead2306/.XWinrc not found LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Done parsing the configuration file... winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD winDetectSupportedEngines - Windows NT, allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL winDetectSupportedEngines - Returning, supported engines 001f winSetEngine - Multi Window or Rootless = ShadowGDI winScreenInit - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 2944 height: 1280 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Calling pthread_mutex_lock () Screen 0 added at virtual desktop coordinate (1024,0). MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 4 [main] X 15760 fork: child 19360 - died waiting for dll loading, errno 11 startxwin: giving up startxwin: unable to connect to X server: Connection refused startxwin: server error The culprit seems the line saying died waiting for dll loading, errno 11. Knowing which dll didn't load could help, I guess... What's annoying is the fact that this used to work really fine up until about 1 week ago... Thanks! Denis
Re: X won't start anymore
On 10/19/2011 4:17 PM, Denis Beauchemin wrote: Hello, I guess it happened after some MS update but I can't start X anymore (from an rxvt-native console since clicking the desktop icon doesn't display anything): $ startxwin.exe Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.11.1.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.11.1-1 built 2011-10-05 XWin was started with the following command line: X :0 -multiwindow (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/bead2306/.XWinrc not found LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Done parsing the configuration file... winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD winDetectSupportedEngines - Windows NT, allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL winDetectSupportedEngines - Returning, supported engines 001f winSetEngine - Multi Window or Rootless = ShadowGDI winScreenInit - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 2944 height: 1280 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Calling pthread_mutex_lock () Screen 0 added at virtual desktop coordinate (1024,0). MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (II) AIGLX: Loaded and initialized swrast (II) GLX: Initialized DRISWRAST GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 4 [main] X 15760 fork: child 19360 - died waiting for dll loading, errno 11 startxwin: giving up startxwin: unable to connect to X server: Connection refused startxwin: server error The culprit seems the line saying died waiting for dll loading, errno 11. Knowing which dll didn't load could help, I guess... What's annoying is the fact that this used to work really fine up until about 1 week ago... Thanks! Denis latest cygwin snapshot are more informative about fork failures, eventually you can try them http://cygwin.com/snapshots/ Regards Marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: {libtasn1/libtasn13/libtasn1-devel}-2.9-1: Tiny ASN.1 library
Hi New versions of 'libtasn1/libtasn13/libtasn1-devel' have been uploaded to a server near you. o Update to latest upstream release o Build for cygwin 1.7.9 with gcc-4.5.3 libtasn1 NEWS: === * Noteworthy changes in release 2.9 (2010-12-06) [stable] - tests: Link to gnulib to avoid build error related to 'rpl_ftello' on Solaris. Reported by Dagobert Michelsen. - doc: Fix bug reporting address to point at help-libta...@gnu.org. - doc: Fix Returns: documentation in Texinfo. Reported by Jeffrey Walton. - build: Update gnulib files. * Noteworthy changes in release 2.8 (2010-09-25) [stable] - Update gnulib files. - Use Libtool 2.2.10 to ease MinGW64 builds. * Noteworthy changes in release 2.7 (2010-05-20) [stable] - Doc: Build a PDF manual using GTK-DOC. - Doc: Fix of asn1_check_version, documentation was missing from last release. - Build: Avoid warnings about ignored visibility attributes on Windows. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
How to run a bash script that calls a Win exe under Windows without installing Cygwin?
Dear all, I have gone through Cygwin FAQ and documentation, did some googling but could not find any answer to my cross system problem. I currently work under Win Vista and have a proper Cygwin installation running perfectly. I have to perform heavy tests on a Windows console executable program say: MYPROG.exe (obtained by using MS Visual Studio). To test such a program I have written a bash shell script, say: MYSHELL.sh, that does the following things: 1/ Build up data files 2/ Launch my Win exe: MYPROG.exe 3/ Organise all the resulting data This procedure works perfectly on my own machine and all my tests are performed by only running MYSHELL.sh in my Cygwin console. Now, I need to perform the same test procedure on another Win Vista machine where Cygwin is not installed. I therefore have to find a solution around the Win prompt (cmd.exe). Basically, I can copy anything on that machine but I cannot install Cygwin. Is there a way to run my script MYSHELL.sh within Win prompt by only copying Cygwin dll (cygwin1.dll) at the right place and maybe changing some settings ? Would it be possible (better) to adopt another strategy that would be to write a macro Win console exe file that can run in the Win prompt and that would kind of embed / link with: cygwin1.dll, MYSHELL.sh, MYPROG.exe ? I thank you in advance for any suggestion. Bagvian -- 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
Re: How to run a bash script that calls a Win exe under Windows without installing Cygwin?
19.10.2011 10:57, bagvian пишет: Dear all, I have gone through Cygwin FAQ and documentation, did some googling but could not find any answer to my cross system problem. I currently work under Win Vista and have a proper Cygwin installation running perfectly. I have to perform heavy tests on a Windows console executable program say: MYPROG.exe (obtained by using MS Visual Studio). To test such a program I have written a bash shell script, say: MYSHELL.sh, that does the following things: 1/ Build up data files 2/ Launch my Win exe: MYPROG.exe 3/ Organise all the resulting data This procedure works perfectly on my own machine and all my tests are performed by only running MYSHELL.sh in my Cygwin console. Now, I need to perform the same test procedure on another Win Vista machine where Cygwin is not installed. I therefore have to find a solution around the Win prompt (cmd.exe). Basically, I can copy anything on that machine but I cannot install Cygwin. Is there a way to run my script MYSHELL.sh within Win prompt by only copying Cygwin dll (cygwin1.dll) at the right place and maybe changing some settings ? Would it be possible (better) to adopt another strategy that would be to write a macro Win console exe file that can run in the Win prompt and that would kind of embed / link with: cygwin1.dll, MYSHELL.sh, MYPROG.exe ? I thank you in advance for any suggestion. Run ldd `which bash` and copy to new host all listen dll with bash in same dir. -- 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
How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files? I customize HG templates under: /lib/python2.6/site-packages/mercurial/templates/gitweb/* and would like preserve it when update happen. And it will be good to be notified if conflict happen. Also I try: $ cygcheck -c mercurial Cygwin Package Information Package VersionStatus mercurial1.9.2-1OK when I try: $ mv /lib/python2.6/site-packages/mercurial/templates/gitweb/branches.tmpl /lib/python2.6/site-packages/mercurial/templates/gitweb/branches~.tmpl $ cygcheck -c mercurial Cygwin Package Information Package VersionStatus mercurial1.9.2-1Incomplete So cygcheck -c does not provide ability to find modification to package files. Also I worry about modification in other config files in /etc (like /etc/apache2/httpd.conf). Are they overwritten on package update? How can I be notified about upgrade conflicts? What for '/etc/defaults' hierarchy was used? -- 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
A quick question regarding a recent commit
Hi Corinna, Apologies for emailing you direct, normally I would go through the mailing lists etc but it's a really quick question which I'm hoping you can answer in about 10 seconds. You recently applied a patch to the Cygwin tree regarding Windows permissions when logging in via SSH with PubKey authentication (see the link below). Another user in the thread confirmed it worked in the latest snapshot. I download the latest cygwin-inst tar ball and replaced the existing installed files on a machine that is suffering from the same issue (with the ones from the archive). After rebooting the machine the issue still persisted though :-( (trying to install an MSI as administrator, works with password auth, not with pub key). Do I need to build all of Cygwin from scratch (including packages such as SSHd) or should the above have worked? Apologies for my n00bishness, http://thread.gmane.org/gmane.os.cygwin/128472 Thanks again for your help. Regards Stuart -- 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
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
Also I worry about modification in other config files in /etc (like /etc/apache2/httpd.conf). Are they overwritten on package update? This is up to each package maintainer. Current best practice - at least, as of a year or two ago when I asked about it on cygwin-apps I think - is to include: (1) a default config file in /etc/defaults/etc; (2) a preremove script that removes the existing config file iff it hasn't change from the default; and (3) a postinstall script that installs the default config into /etc if no other config file is already there. If all three of those are present, then a package upgrade will replace the existing config files if and only if they haven't changed since they were installed. If they have changed, then it's up to the user to merge the old and new configs. cygport provides automatic support for (1) and (3) above if you call e.g. make_etc_defaults /etc/lftp.conf To complete the set, package maintainers have to separately include a simple preremove script, e.g. if cmp -s /etc/defaults/etc/lftp.conf /etc/lftp.conf then /bin/rm /etc/lftp.conf fi The lftp package, for example, includes all three of the above pieces. For other packages, you'll just have to check each one. If a piece seems to be missing, you can ask the maintainer if they're willing to add it. How can I be notified about upgrade conflicts? Unfortunately, setup doesn't include any way of prompting the user for action due to conflicts. The postinstall script will either overwrite the existing config, or it won't. I think it's considered bad practice to overwrite a config without checking first whether it's been modified; if you find that a package does that, you should ask the maintainer to fix it. Your safest bet is probably to back up all of the configuration before you upgrade. What for '/etc/defaults' hierarchy was used? See above. -- 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
Question about Cygwin's select()
I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Ken -- 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
Re: A quick question regarding a recent commit
You recently applied a patch to the Cygwin tree regarding Windows permissions when logging in via SSH with PubKey authentication (see the link below). Another user in the thread confirmed it worked in the latest snapshot. I download the latest cygwin-inst tar ball and replaced the existing installed files on a machine that is suffering from the same issue (with the ones from the archive). After rebooting the machine the issue still persisted though :-( (trying to install an MSI as administrator, works with password auth, not with pub key). Please log in with pubkey and run /cygdrive/c/Windows/System32/whoami /all Then post the results here. That will show which privileges your account has, and whether they're enabled. -- 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
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
19.10.2011 16:27, Andrew Schulman пишет: Also I worry about modification in other config files in /etc (like /etc/apache2/httpd.conf). Are they overwritten on package update? This is up to each package maintainer. Current best practice - at least, as of a year or two ago when I asked about it on cygwin-apps I think - is to include: (1) a default config file in /etc/defaults/etc; (2) a preremove script that removes the existing config file iff it hasn't change from the default; and (3) a postinstall script that installs the default config into /etc if no other config file is already there. If all three of those are present, then a package upgrade will replace the existing config files if and only if they haven't changed since they were installed. If they have changed, then it's up to the user to merge the old and new configs. cygport provides automatic support for (1) and (3) above if you call e.g. make_etc_defaults /etc/lftp.conf To complete the set, package maintainers have to separately include a simple preremove script, e.g. if cmp -s /etc/defaults/etc/lftp.conf /etc/lftp.conf then /bin/rm /etc/lftp.conf fi The lftp package, for example, includes all three of the above pieces. For other packages, you'll just have to check each one. If a piece seems to be missing, you can ask the maintainer if they're willing to add it. How can I be notified about upgrade conflicts? Unfortunately, setup doesn't include any way of prompting the user for action due to conflicts. The postinstall script will either overwrite the existing config, or it won't. I think it's considered bad practice to overwrite a config without checking first whether it's been modified; if you find that a package does that, you should ask the maintainer to fix it. Your safest bet is probably to back up all of the configuration before you upgrade. What for '/etc/defaults' hierarchy was used? See above. Thanks for replay! Seems that /etc/default practice is good. How about templates? For example if package like Mercurial provide WEB templates which I like to customize (fix time format to ISO-8601). Templates lies in /lib/python2.6/site-packages/mercurial/templates/*. If I prepare some fixes to package which list appropriate to write report to? Contact to mail from /usr/share/doc/Cygwin/*.README or separate list used for this purpose? -- 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
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
How about templates? For example if package like Mercurial provide WEB templates which I like to customize (fix time format to ISO-8601). Templates lies in /lib/python2.6/site-packages/mercurial/templates/*. It seems that that's something you'll have to work out with the Mercurial package maintainer. A postinstall script can certainly check to see if templates have changed, and if they have either leave them in place, or even merge in new changes, if you can work out a good way to do that without prompting the user. If I prepare some fixes to package which list appropriate to write report to? This is the right list. If you put mercurial in the subject, the maintainer will probably see it. Good luck, Andrew. -- 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
Re: How to run a bash script that calls a Win exe under Windows without installing Cygwin?
On 10/19/2011 02:57, bagvian wrote: Dear all, I have gone through Cygwin FAQ and documentation, did some googling but could not find any answer to my cross system problem. I currently work under Win Vista and have a proper Cygwin installation running perfectly. I have to perform heavy tests on a Windows console executable program say: MYPROG.exe (obtained by using MS Visual Studio). To test such a program I have written a bash shell script, say: MYSHELL.sh, that does the following things: 1/ Build up data files 2/ Launch my Win exe: MYPROG.exe 3/ Organise all the resulting data This procedure works perfectly on my own machine and all my tests are performed by only running MYSHELL.sh in my Cygwin console. Now, I need to perform the same test procedure on another Win Vista machine where Cygwin is not installed. I therefore have to find a solution around the Win prompt (cmd.exe). Basically, I can copy anything on that machine but I cannot install Cygwin. Is there a way to run my script MYSHELL.sh within Win prompt by only copying Cygwin dll (cygwin1.dll) at the right place and maybe changing some settings ? Would it be possible (better) to adopt another strategy that would be to write a macro Win console exe file that can run in the Win prompt and that would kind of embed / link with: cygwin1.dll, MYSHELL.sh, MYPROG.exe ? I thank you in advance for any suggestion. Copying around a partial Cygwin installation is definitely not supported on this list. It can certainly be done, but you'll be on your own when it breaks down. Depending on the needs of your script, you may also find the task of gathering everything together to be cumbersome. If you truly can't install anything onto the test system by way of a proper installation program, you're probably better off replacing MYSHELL.sh with something else that already is available natively on the system. There are a number of options potentially available to you including cmd, Windows Script Host, and PowerShell. FYI, the Cygwin installation isn't really much more than a reliable and supported way to get the things you need for Cygwin copied to the right location on your hard drive. The setup program only adds a few things to the registry aside from copying files into place, and you can probably delete those registry entries after setup completes without affecting Cygwin itself. Actually installing Cygwin shouldn't adversely affect anything else on the system that isn't already aware of Cygwin, so if you really do need Cygwin or parts of it, you should try to argue for Cygwin's inclusion on the test machine. It sounds like you might be better served by one of the alternatives I mentioned though. -Jeremy -- 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
Re: A quick question regarding a recent commit
On Oct 19 09:58, Andrew Schulman wrote: You recently applied a patch to the Cygwin tree regarding Windows permissions when logging in via SSH with PubKey authentication (see the link below). Another user in the thread confirmed it worked in the latest snapshot. I download the latest cygwin-inst tar ball and replaced the existing installed files on a machine that is suffering from the same issue (with the ones from the archive). After rebooting the machine the issue still persisted though :-( (trying to install an MSI as administrator, works with password auth, not with pub key). Please log in with pubkey and run /cygdrive/c/Windows/System32/whoami /all Then post the results here. That will show which privileges your account has, and whether they're enabled. This is probably not the same problem. The solution for these cases is either to just stick to password auth, or to use the passwordless setuid methods 2 or 3 as outlined in http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview This should fix this kind of problem, especially method 3. 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
Re: Question about Cygwin's select()
On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. 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
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
On 10/19/2011 09:13, Andrew Schulman wrote: How about templates? For example if package like Mercurial provide WEB templates which I like to customize (fix time format to ISO-8601). Templates lies in /lib/python2.6/site-packages/mercurial/templates/*. It seems that that's something you'll have to work out with the Mercurial package maintainer. A postinstall script can certainly check to see if templates have changed, and if they have either leave them in place, or even merge in new changes, if you can work out a good way to do that without prompting the user. According to this page, you can change where hgweb looks for templates by editing either /etc/mercurial/hgrc or the .hgrc file in the home directory of the user running hgweb: http://mercurial.selenic.com/wiki/Theming Rather than making a complex postinstall script than can manage overrides sanely, it would be better to copy the packaged template files into a new location outside of the paths managed by the packages and then configure hgweb to look for them in the new location. You'll then be free to make any changes you like then without fear that they will be inadvertently clobbered. -Jeremy -- 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
rm -rf cannot delete the upmost directory level anymore on a Novell share
Hi, sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' Looking at the strace output of both rm-7.0 and rm-8.10 it seems that rm-8.10 thinks that lev1 is a file, because it uses unlink_nt() first. ... 3866 164248 [main] rm-8.10 336 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2/lev3) 295 164543 [main] rm-8.10 336 close: close (5) 231 164774 [main] rm-8.10 336 fhandler_base::close: closing '/test_rm_rf/lev1/lev2' handle 0x6FC 150 164924 [main] rm-8.10 336 close: 0 = close (5) 252 165176 [main] rm-8.10 336 normalize_posix_path: src /test_rm_rf/lev1/lev2 128 165304 [main] rm-8.10 336 normalize_posix_path: /test_rm_rf/lev1/lev2 = normalize_posix_path (/test_rm_rf/lev1/lev2) 267 165571 [main] rm-8.10 336 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1/lev2) 133 165704 [main] rm-8.10 336 set_flags: flags: binary (0x2) 266 165970 [main] rm-8.10 336 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1/lev2, dst J:\FRA\test_rm_rf\lev1\lev2, flags 0x3000A, rc 0 333 166303 [main] rm-8.10 336 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1\lev2) 345 166648 [main] rm-8.10 336 symlink_info::check: not a symlink 402 167050 [main] rm-8.10 336 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1\lev2, 0x22B5D0) (0x3000A) 252 167302 [main] rm-8.10 336 path_conv::check: this-path(J:\FRA\test_rm_rf\lev1\lev2), has_acls(0) 270 167572 [main] rm-8.10 336 build_fh_pc: fh 0x61256C7C, dev 0xC3 3861 171433 [main] rm-8.10 336 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2) 167 171600 [main] rm-8.10 336 normalize_posix_path: src /test_rm_rf/lev1 229 171829 [main] rm-8.10 336 normalize_posix_path: /test_rm_rf/lev1 = normalize_posix_path (/test_rm_rf/lev1) 398 172227 [main] rm-8.10 336 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1) 399 172626 [main] rm-8.10 336 set_flags: flags: binary (0x2) 133 172759 [main] rm-8.10 336 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1, dst J:\FRA\test_rm_rf\lev1, flags 0x3000A, rc 0 318 173077 [main] rm-8.10 336 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1) 227 173304 [main] rm-8.10 336 symlink_info::check: not a symlink 268 173572 [main] rm-8.10 336 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1, 0x22B5D0) (0x3000A) 253 173825 [main] rm-8.10 336 path_conv::check: this-path(J:\FRA\test_rm_rf\lev1), has_acls(0) 535 174360 [main] rm-8.10 336 build_fh_pc: fh 0x61256C7C, dev 0xC3 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete failed, status = 0xC043 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC043 - windows error 32 210 175026 [main] rm-8.10 336 geterrno_from_win_error: windows error 32 == errno 16 263 175289 [main] rm-8.10 336 rmdir: -1 = rmdir (/test_rm_rf/lev1) ... This happens both on XPSP3 (NWFS, Novell Client 4.91SP5IR1) and Win7SP1 (NcFsd, NovellClient2 SP1 IR9a). The strace was done on XP. Does this ring a bell for anyone? What else can I do to track down the cause? It cannot be so simple like rm-8.10 forgetting to close the open FDs of lev1 before trying to delete it? That was the only thing that jumped to my eyes while looking at the strace. Franz Sirl -- 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
Re: How to run a bash script that calls a Win exe under Windows without installing Cygwin?
On 10/19/11 00:57, bagvian wrote: Basically, I can copy anything on that machine but I cannot install Cygwin. If you can truly copy anything on that machine then why not simply copy desktop:C:\Cygwin to that machine? -- Andrew DeFaria http://defaria.com Out of my mind. Back in five minutes. -- 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
Re: Question about Cygwin's select()
On 10/19/2011 10:49 AM, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. Sorry for the missing details. Emacs uses a pseudo tty. I'm currently using the latest Cygwin snapshot, but I'm pretty sure I saw the same behavior with 1.7.9. I'll recheck that. My workaround is to force emacs to check for process output earlier in the initialization phase. For reasons I don't understand, the select call used at that point always succeeds. I think you've answered my basic question by saying that the EINTR sounds weird. I'll try to make a testcase. Ken -- 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
Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
On Oct 19 17:12, Franz Sirl wrote: Hi, sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' The problem is, it works fine on local and remote NTFS, as well as on Samba. Since the number of open handles doesn't depend on the underlying filesystem, why should it fail for NWFS? Looking at the strace output of both rm-7.0 and rm-8.10 it seems that rm-8.10 thinks that lev1 is a file, because it uses unlink_nt() first. unlink_nt is used by unlink as well as by rmdir since the system calls to delete a file are the same as the calls to delete a directory. 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete failed, status = 0xC043 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC043 - windows error 32 That's a sharing violation. Where's the difference to the strace output with the exact same Cygwin DLL and rm from coreutils 7? 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
Re: Question about Cygwin's select()
On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. cgf -- 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
Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-19 17:45, schrieb Corinna Vinschen: On Oct 19 17:12, Franz Sirl wrote: Hi, sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't have any other in between versions anymore) this simple command started to fail: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' rm: cannot remove `lev1': Device or resource busy Tested with coreutils-8.10 and cygwin1.dll from the 20111017 snapshot, as the cygwin1.dll didn't make any difference for the problem. If I just use rm.exe from coreutils-7.0 everything starts to work as expected again: # mkdir -p lev1/lev2/lev3 # rm -rfv lev1 removed directory: `lev1/lev2/lev3' removed directory: `lev1/lev2' removed directory: `lev1' The problem is, it works fine on local and remote NTFS, as well as on Samba. Since the number of open handles doesn't depend on the underlying filesystem, why should it fail for NWFS? True. But on the other hand NWFS and NcFsd exercise a lot of pathes in the Cygwin sourcecode that aren't usually used. Even between NWFS on XP and NcFsd on Win7 there are differences, because fs.is_nwfs() doesn't trigger on Win7 with the Novell Client (the filesystem name is different). If it turns out to be a problem in the Novell Client, I can work with Novell to fix it (for the Vista/Win7 client), but right now I'm not sure who's problem it is. Looking at the strace output of both rm-7.0 and rm-8.10 it seems that rm-8.10 thinks that lev1 is a file, because it uses unlink_nt() first. unlink_nt is used by unlink as well as by rmdir since the system calls to delete a file are the same as the calls to delete a directory. I see. 216 174576 [main] rm-8.10 336 unlink_nt: Opening file for delete failed, status = 0xC043 240 174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC043 - windows error 32 That's a sharing violation. Where's the difference to the strace output with the exact same Cygwin DLL and rm from coreutils 7? Hmm, I just see that on Win7 the errorcode for unlink_nt is different, for completeness: ... 2046 158907 [main] rm-8.10 2940 unlink_nt: Setting delete disposition failed, status = 0xC121 594 159501 [main] rm-8.10 2940 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/fhandler_disk_file.cc:1735 status 0xC121 - windows error 5 193 159694 [main] rm-8.10 2940 geterrno_from_win_error: windows error 5 == errno 13 283 159977 [main] rm-8.10 2940 rmdir: -1 = rmdir (/test_rm_rf/lev1) ... The strace from rm-7.0 on XP looks like this: ... 3998 159342 [main] rm-7.0 360 rmdir: 0 = rmdir (/test_rm_rf/lev1/lev2/lev3) 435 159777 [main] rm-7.0 360 fhandler_base::set_close_on_exec: set close_on_exec for /test_rm_rf/lev1/lev2 to 1 225 160002 [main] rm-7.0 360 fhandler_disk_file::opendir: 0x20044A20 = opendir (/test_rm_rf/lev1/lev2) 272 160274 [main] rm-7.0 360 fhandler_base::fstat_helper: 0 = fstat (\??\J:\FRA\test_rm_rf\lev1\lev2, 0x22C7D0) st_size=0, st_mode=0x41ED, st_ino=-5551660102295404609st_atim=0.0 st_ctim=4E9EE2B4.0 st_mtim=4E9EE2B4.0 st_birthtim=4E9EE2B4.0 258 160532 [main] rm-7.0 360 fstat64: 0 = fstat (4, 0x22C7D0) 788 161320 [main] rm-7.0 360 fhandler_disk_file::readdir: 0 = readdir (0x20044A20, 0x22C704) (L. .) (attr 0x10 type 4) 146 161466 [main] rm-7.0 360 fhandler_disk_file::readdir: 0 = readdir (0x20044A20, 0x22C704) (L.. ..) (attr 0x10 type 4) 265 161731 [main] rm-7.0 360 normalize_posix_path: src /test_rm_rf/lev1/lev2/.. 132 161863 [main] rm-7.0 360 normalize_posix_path: /test_rm_rf/lev1/ = normalize_posix_path (/test_rm_rf/lev1/lev2/..) 266 162129 [main] rm-7.0 360 mount_info::conv_to_win32_path: conv_to_win32_path (/test_rm_rf/lev1) 134 162263 [main] rm-7.0 360 set_flags: flags: binary (0x2) 266 162529 [main] rm-7.0 360 mount_info::conv_to_win32_path: src_path /test_rm_rf/lev1, dst J:\FRA\test_rm_rf\lev1, flags 0x3000A, rc 0 198 162727 [main] rm-7.0 360 symlink_info::check: 0x0 = NtCreateFile (\??\J:\FRA\test_rm_rf\lev1) 214 162941 [main] rm-7.0 360 symlink_info::check: not a symlink 254 163195 [main] rm-7.0 360 symlink_info::check: 0 = symlink.check (J:\FRA\test_rm_rf\lev1, 0x22B350) (0x43000A) 266 163461 [main] rm-7.0 360 path_conv::check: this-path(J:\FRA\test_rm_rf\lev1), has_acls(0) 290 163751 [main] rm-7.0 360 geterrno_from_win_error: windows error 18 == errno 89 243 163994 [main] rm-7.0 360 fhandler_disk_file::readdir: 89 = readdir (0x20044A20, 0x22C704) (L(null) ***) (attr 0x0 type 0) 269 164263 [main] rm-7.0 360 fcntl64: 1 = fcntl (4, 1, 0x8) 295 164558 [main] rm-7.0 360 open: open (/test_rm_rf/lev1/lev2/.., 0x0) 235 164793 [main] rm-7.0 360 normalize_posix_path: src /test_rm_rf/lev1/lev2/.. 265 165058 [main] rm-7.0 360 normalize_posix_path: /test_rm_rf/lev1/ = normalize_posix_path
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
On Wed, 2011-10-19 at 09:27 -0400, Andrew Schulman wrote: This is up to each package maintainer. Current best practice - at least, as of a year or two ago when I asked about it on cygwin-apps I think - is to include: (1) a default config file in /etc/defaults/etc; (2) a preremove script that removes the existing config file iff it hasn't change from the default; and (3) a postinstall script that installs the default config into /etc if no other config file is already there. If all three of those are present, then a package upgrade will replace the existing config files if and only if they haven't changed since they were installed. If they have changed, then it's up to the user to merge the old and new configs. cygport provides automatic support for (1) and (3) above if you call e.g. make_etc_defaults /etc/lftp.conf To complete the set, package maintainers have to separately include a simple preremove script, e.g. Actually, cygport handles (2) as well. No further intervention should be necessary once make_etc_defaults is called. Yaakov -- 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
Re: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?
To complete the set, package maintainers have to separately include a simple preremove script, e.g. Actually, cygport handles (2) as well. No further intervention should be necessary once make_etc_defaults is called. I was hoping you'd say that. New feature in the last year or two? -- 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
Re: Question about Cygwin's select()
On 10/19/2011 12:22 PM, Christopher Faylor wrote: On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. I'm getting the EINTR by examining errno while running the program under gdb. But thanks for the heads-up about strace. I didn't know that. Ken -- 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
Re: Question about Cygwin's select()
On 10/19/2011 1:32 PM, Ken Brown wrote: On 10/19/2011 12:22 PM, Christopher Faylor wrote: On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. I'm getting the EINTR by examining errno while running the program under gdb. But thanks for the heads-up about strace. I didn't know that. I don't have a testcase yet, but I have a clearer idea of what's happening. It actually has nothing to do with the gdb subprocess, but rather is a problem that can occur whenever emacs is running its main command loop. emacs polls for keyboard input while also using select to check for output from subprocesses. It's in this setting that select often fails with EINTR, even when there are no subprocesses running. I wonder if the keyboard polling is doing something that interrupts the select call. Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and timers and other things I know nothing about, so it's not going to be easy for me to come up with an STC. I'll see if I can get help on the emacs-devel list. Ken -- 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
Re: Question about Cygwin's select()
On Wed, Oct 19, 2011 at 4:15 PM, Ken Brown kbr...@cornell.edu wrote: On 10/19/2011 1:32 PM, Ken Brown wrote: On 10/19/2011 12:22 PM, Christopher Faylor wrote: On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. I'm getting the EINTR by examining errno while running the program under gdb. But thanks for the heads-up about strace. I didn't know that. I don't have a testcase yet, but I have a clearer idea of what's happening. It actually has nothing to do with the gdb subprocess, but rather is a problem that can occur whenever emacs is running its main command loop. emacs polls for keyboard input while also using select to check for output from subprocesses. It's in this setting that select often fails with EINTR, even when there are no subprocesses running. I wonder if the keyboard polling is doing something that interrupts the select call. Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and timers and other things I know nothing about, so it's not going to be easy for me to come up with an STC. I'll see if I can get help on the emacs-devel list. Ken Any code calling select (and many other kernel calls) must handle the case of the call returning EINTR for many (or no particular) reason(s). If emacs is assuming certain calls under certain conditions will never return EINTR, then it is definitely not written robustly. Jon -- 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
building a cygwin aware GHC
I am attempting (for probably the tenth time) to compile the GHC haskell compiler. The problem with GHC is that the windows version is compiled with MinGW, and cygwin is considered to be nothing other than a MinGW alternative. IOW, the source code is riddled with assumptions that if you are building GHC with cygwin then what you want in the end is a cygwin-unaware windows-compliant executable. I have attempted in the past to modify configure(.ac) to trick the build system into thinking that the target OS is an unknown unix platform, but IIRC that failed during the compilation of some code inside a #ifdef WIN32 block. This time I'm thinking I will go through the source and expunge all code that's conditional for MinGW, CYGWIN32, WIN32_*, etc. After an autoreconf the autobuild system's innate awareness of cygwin should allow me to build as if the target is some generic unix-like system. Before I get started, I'm wondering if anyone has tried anything like this before and has any tips. Are there any win32 related CFLAGS that I want to leave alone or can I expunge them all? regards, NT -- 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
Re: building a cygwin aware GHC
Nathan Thern writes: The problem with GHC is that the windows version is compiled with MinGW, and cygwin is considered to be nothing other than a MinGW alternative. IOW, the source code is riddled with assumptions that if you are building GHC with cygwin then what you want in the end is a cygwin-unaware windows-compliant executable. Rather than using the windows version is there a Linux or Unix version you could start with? That path might be easier to get running under Cygwin. ..mark -- 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
Re: [ANNOUNCEMENT] Updated: binutils-2.22.51-1
On 18/10/2011 3:03 PM, Christopher Faylor wrote: I've made a new version of binutils available for installation. This is a refresh against CVS. The contents of the NEWS file for this snapshot are in /usr/share/doc/Cygwin/binutils-2.22.51-1.README . The main reason for the release is to pull in Dave Korn's changes as discussed here: http://cygwin.com/ml/cygwin/2011-09/msg00386.html Dave, will there also be a new gcc to address the relocation issue with libstdc++? Cheers, Chris -- Chris Sutcliffe ir0nh...@gmail.com http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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
Re: Question about Cygwin's select()
On 10/19/2011 4:30 PM, Jon Clugston wrote: On Wed, Oct 19, 2011 at 4:15 PM, Ken Brownkbr...@cornell.edu wrote: On 10/19/2011 1:32 PM, Ken Brown wrote: On 10/19/2011 12:22 PM, Christopher Faylor wrote: On Wed, Oct 19, 2011 at 04:49:10PM +0200, Corinna Vinschen wrote: On Oct 19 09:28, Ken Brown wrote: I'm trying to debug an emacs problem, and I'm running into something I don't understand involving Cygwin's select. I'll try to make an STC if necessary, but I thought I'd start with a verbal description in case there's an easy answer. Here's the situation: emacs creates a subprocess running gdb and sends a bunch of commands to gdb without immediately reading the resulting output. emacs then goes into a loop in which it waits for keyboard input and periodically calls select to check for output from subprocesses. The first call to select has a 30 second timeout and *always* fails with EINTR. As a result, emacs doesn't read the output from gdb right away and doesn't properly initialize the gdb buffer. Subsequent calls to select sometimes succeed and sometimes fail. When I'm running emacs under gdb and stepping through it, the buffer eventually gets initialized. When I'm running emacs outside of gdb, the buffer doesn't get initialized until I press Return. I have a simple workaround for this, but I'd like to be sure there isn't some underlying bug that I'm masking with the workaround. So my question is this: Is there some reason that I should expect that first call to select to consistently fail with EINTR, or might this indicate a bug? I realize that it might not be possible to answer the question based on the information I've provided, but I thought it was worth a try. Some details are missing like the objects used to communicate with GDB. Does Emacs use a pseudo tty or a pipe? Is that with Cygwin from CVS or with 1.7.9? And what's your workaround? The EINTR sounds weird. A testcase would be most helpful. It isn't clear if you're getting the EINTR by looking at strace output or from the code. If it's strace then be aware that sometimes the output just reports the current errno regardless of whether there is an error or not. I'm getting the EINTR by examining errno while running the program under gdb. But thanks for the heads-up about strace. I didn't know that. I don't have a testcase yet, but I have a clearer idea of what's happening. It actually has nothing to do with the gdb subprocess, but rather is a problem that can occur whenever emacs is running its main command loop. emacs polls for keyboard input while also using select to check for output from subprocesses. It's in this setting that select often fails with EINTR, even when there are no subprocesses running. I wonder if the keyboard polling is doing something that interrupts the select call. Unfortunately, the keyboard code (in src/keyboard.c) is full of alarms and timers and other things I know nothing about, so it's not going to be easy for me to come up with an STC. I'll see if I can get help on the emacs-devel list. Ken Any code calling select (and many other kernel calls) must handle the case of the call returning EINTR for many (or no particular) reason(s). If emacs is assuming certain calls under certain conditions will never return EINTR, then it is definitely not written robustly. emacs does handle the EINTR. Sorry if I suggested otherwise. I was just surprised that I was getting that error so often, and I thought it was responsible for the gdb problem I was seeing. I'll keep debugging. Ken -- 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
Re: Contributing license information?
Corinna Vinschen wrote:
On Aug 19 11:09, Luke Kendall wrote:
Soon, I will have prepared a list of the location of every license
file in every Cygwin package. My motivation is to make it easy for
people to find the license information, if they need it.
(Preparing this information has required a lot of work on my part,
so I would be happy if something could be done to make it easy to
keep the information up to date as packages are added and modified.)
What is the best way to contribute the license-location information
so it can be integrated into Cygwin?
Just create a new package for the distro which keeps the information
and maintain it. Somebody will have to keep the information up to date
anyway.
Corinna
Is usr/share/doc/common-licenses/ within the base-files package,
supposed to be the place where all license information is collected?
Should I just use that?
I only today noticed
http://www.cygwin.com/ml/cygwin-apps/2004-06/msg00275.html
I believe usr/share/doc/common-licenses/ lists many licenses that are
not used in the base-files package. I say that because it contains over
a dozen licenses, even though base-files otherwise just contains a few
shell scripts and skeleton files from etc/{defaults,postinstall, preremove}.
What do you think?
Regards,
luke
--
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
Updated: {libtasn1/libtasn13/libtasn1-devel}-2.9-1: Tiny ASN.1 library
Hi New versions of 'libtasn1/libtasn13/libtasn1-devel' have been uploaded to a server near you. o Update to latest upstream release o Build for cygwin 1.7.9 with gcc-4.5.3 libtasn1 NEWS: === * Noteworthy changes in release 2.9 (2010-12-06) [stable] - tests: Link to gnulib to avoid build error related to 'rpl_ftello' on Solaris. Reported by Dagobert Michelsen. - doc: Fix bug reporting address to point at help-libta...@gnu.org. - doc: Fix Returns: documentation in Texinfo. Reported by Jeffrey Walton. - build: Update gnulib files. * Noteworthy changes in release 2.8 (2010-09-25) [stable] - Update gnulib files. - Use Libtool 2.2.10 to ease MinGW64 builds. * Noteworthy changes in release 2.7 (2010-05-20) [stable] - Doc: Build a PDF manual using GTK-DOC. - Doc: Fix of asn1_check_version, documentation was missing from last release. - Build: Avoid warnings about ignored visibility attributes on Windows. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
