[RFU] serf-0.3.1-1
New upstream release. wget -x -nH --cut-dirs=2 \ http://mysite.verizon.net/res00a7j/cygwin/serf/libserf0-devel/libserf0-devel-0.3.1-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/serf/libserf0-devel/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/serf/libserf0_0/libserf0_0-0.3.1-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/serf/libserf0_0/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/serf/serf-0.3.1-1-src.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/serf/setup.hint -- David Rothenberger daver...@acm.org I only know what I read in the papers. -- Will Rogers
[RFU] subversion-1.6.9-2
This release includes the svnmucc tool in the package. No other changes. Please leave version 1.6.6-3 and remove all prior versions. wget -x -nH --cut-dirs=2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.9-2-src.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/subversion-apache2-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/subversion-devel-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/subversion-perl-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/subversion-python-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/subversion-ruby-1.6.9-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-tools/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-tools/subversion-tools-1.6.9-2.tar.bz2 -- David Rothenberger daver...@acm.org timesharing, n: An access method whereby one computer abuses many people.
Please upload: mined-2000.16-0
Please upload the release update package for mined: #mkdir mined cd mined wget http://towo.net/mined/cygwin/mined-2000.16-0.tar.bz2 wget http://towo.net/mined/cygwin/mined-2000.16-0-src.tar.bz2 #wget http://towo.net/mined/cygwin/setup.hint Thank you, Thomas Wolff
How do I start WM?
How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). TIA, Joe -- 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: How do I start WM?
On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx -- 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: How do I start WM?
To: cygwin-xfree@cygwin.com Cc: joseph_...@yahoo.com Sent: Tue, February 23, 2010 9:36:55 AM Subject: Re: How do I start WM? On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx -- Jon TURNEY Volunteer Cygwin/X X Server maintainer From: Jon TURNEY jon.tur...@dronecode.org.uk I've read the documentation. The page you refer to mentions startxwin and startx. As I mentioned before, startxwin is for multi-window only. startx apparently requires a Cygwin shell. I'm trying to start Cygwin/XWindows in full screen mode. Is there something I missed? -- 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: How do I start WM?
On 23/02/2010 15:11, Joseph Ess wrote: Sent: Tue, February 23, 2010 9:36:55 AM Subject: Re: How do I start WM? On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx I've read the documentation. The page you refer to mentions startxwin and startx. As I mentioned before, startxwin is for multi-window only. startx apparently requires a Cygwin shell. I'm trying to start Cygwin/XWindows in full screen mode. Is there something I missed? From your response, it sounds like you haven't actually tried using startx. Perhaps you should follow my suggestion and try it. Then please explain how it differs from what you want to achieve. -- 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: How do I start WM?
On Tue, Feb 23, 2010 at 07:11:09AM -0800, Joseph Ess wrote: To: XXX Cc: XXX Sent: Tue, February 23, 2010 9:36:55 AM Subject: Re: How do I start WM? There is no need to duplicate this. It's all in the header. On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx -- Jon TURNEY Volunteer Cygwin/X X Server maintainer From: Jon TURNEY jon.tur...@dronecode.org.uk I've read the documentation. The page you refer to mentions startxwin and startx. As I mentioned before, startxwin is for multi-window only. startx apparently requires a Cygwin shell. I'm trying to start Cygwin/XWindows in full screen mode. Is there something I missed? From my reading of the documentation, it sounds like you'd get this behavior by adding server options to startxwin: startxwin -- [ server options ] cgf -- 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: bug report/suggested temp. patch: handling bursts of sent keys
On 13/02/2010 20:24, Mark Lillibridge wrote: Jon wrote: Thanks for the patch. Have you actually tested that this resolves your problem? Yes. Of course, really, really large bursts will still fail, but they should be very rare. Perhaps you might try the attached patch, instead, and see if that helps. On 23/01/2010 22:02, Mark Lillibridge wrote: I am not a Windows programmer. Can someone tell me if it's okay for winWindowProc to block? In particular, could we make it block until the mieq queue is not full? I think blocking would just result in a deadlock, as the X server is only single-threaded. The windows message pump is called when the server has no other work to do. This should be documented in [1], although perhaps that is lacking in detail. I notice that winWakeHandler()/winBlockHandler() try to completely empty the windows message queue, which leads to this problem as the server won't get a chance to process anything (draining the mieq queue) until they return. It might be enough to resolve this problem to allow those functions to complete after processing a limited number of events (chosen so as to not overflow the mieq queue), or if they notice that the event queue has crossed some high-water mark threshold. This is an interesting idea; I spent a while looking at WaitFor.c/WaitForSomething, but it's pretty opaque -- couldn't figure out when/under what conditions winWakeHandler is called by it. E.g., what's the actual priority between emptying the queue and processing window messages? Let's see: right at the end of hw/xwin/InitInput.c we open /dev/windows (a special device which becomes ready when there is anything on the windows message queue) and add that to the select mask. When the select returns, all the wakeup handlers are run, including winWakeHandler() which checks the WM message queue. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer 0001-Process-one-Windows-message-per-wakeup-rather-than-a.patch Description: application/itunes-itlp -- 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: Help me
On 02/23/2010 01:10 PM, Skublics Benedek wrote: Dear Cygwin Team, I tried to install cygwin to use xfig. I do everithing that this page said: http://www.cs.usask.ca/~wew036/latex/xfig.html These instructions are out-of-date. Try contacting the author to get them updated to reflect the current state of Cygwin. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: How do I start WM?
- Original Message From: Jon TURNEY jon.tur...@dronecode.org.uk To: cygwin-xfree@cygwin.com Cc: joseph_...@yahoo.com Sent: Tue, February 23, 2010 11:19:40 AM Subject: Re: How do I start WM? On 23/02/2010 15:11, Joseph Ess wrote: Sent: Tue, February 23, 2010 9:36:55 AM Subject: Re: How do I start WM? On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx I've read the documentation. The page you refer to mentions startxwin and startx. As I mentioned before, startxwin is for multi-window only. startx apparently requires a Cygwin shell. I'm trying to start Cygwin/XWindows in full screen mode. Is there something I missed? From your response, it sounds like you haven't actually tried using startx. And you'd be wrong. Perhaps you should follow my suggestion and try it. I double-clicked on c:\cygwin\bin\startx. It opens a dialog titled Open With that instructs one to Choose the program you want to use to open this file. Then please explain how it differs from what you want to achieve. It doesn't start XWindows like startxwin.bat used to. -- 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: How do I start WM?
On 23/02/2010 18:29, Joseph Ess wrote: Perhaps you should follow my suggestion and try it. I double-clicked on c:\cygwin\bin\startx. It opens a dialog titled Open With that instructs one to Choose the program you want to use to open this file. Does http://x.cygwin.com/docs/ug/using.html#using-starting-startx say to run startx by double clicking on it? Not it does not. Hint: that will not work as startx is bash script, which Windows explorer has no idea how to run. -- 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: How do I start WM?
- Original Message From: Jon TURNEY jon.tur...@dronecode.org.uk To: cygwin-xfree@cygwin.com Cc: joseph_...@yahoo.com Sent: Tue, February 23, 2010 1:49:56 PM Subject: Re: How do I start WM? On 23/02/2010 18:29, Joseph Ess wrote: Perhaps you should follow my suggestion and try it. I double-clicked on c:\cygwin\bin\startx. It opens a dialog titled Open With that instructs one to Choose the program you want to use to open this file. Does http://x.cygwin.com/docs/ug/using.html#using-starting-startx say to run startx by double clicking on it? Not it does not. Hint: that will not work as startx is bash script, which Windows explorer has no idea how to run. I say that I'm trying to replace a .bat file, which one could presumable run by double-clicking on it, and you propose using a bash script, which one cannot double-click on and then berate me for trying it? -- 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: How do I start WM?
On Tue, Feb 23, 2010 at 11:04:20AM -0800, Joseph Ess wrote: - Original Message From: Jon TURNEY jon.tur...@dronecode.org.uk To: cygwin-xfree@cygwin.com Cc: joseph_...@yahoo.com Sent: Tue, February 23, 2010 1:49:56 PM Subject: Re: How do I start WM? On 23/02/2010 18:29, Joseph Ess wrote: Perhaps you should follow my suggestion and try it. I double-clicked on c:\cygwin\bin\startx. It opens a dialog titled Open With that instructs one to Choose the program you want to use to open this file. Does http://x.cygwin.com/docs/ug/using.html#using-starting-startx say to run startx by double clicking on it? Not it does not. Hint: that will not work as startx is bash script, which Windows explorer has no idea how to run. I say that I'm trying to replace a .bat file, which one could presumable run by double-clicking on it, and you propose using a bash script, which one cannot double-click on and then berate me for trying it? Assuming that a .bat file means I'm double clicking something is actually sort of a stretch. But, if you need a .bat files why not just put the call to startx in a .bat file? You'd have to set the PATH appropriately, of course. It seems like you should be able to call startxwin.exe directly if needed too. cgf -- 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: How do I start WM?
On 23/02/2010 19:04, Joseph Ess wrote: On 23/02/2010 18:29, Joseph Ess wrote: Perhaps you should follow my suggestion and try it. I double-clicked on c:\cygwin\bin\startx. It opens a dialog titled Open With that instructs one to Choose the program you want to use to open this file. Does http://x.cygwin.com/docs/ug/using.html#using-starting-startx say to run startx by double clicking on it? Not it does not. Hint: that will not work as startx is bash script, which Windows explorer has no idea how to run. I say that I'm trying to replace a .bat file, which one could presumable run by double-clicking on it, and you propose using a bash script, which one cannot double-click on and then berate me for trying it? Your question was How do I start XWindows in full screen mode with OpenBox window manager?, not How do I start XWindows in full screen mode with OpenBox window manager by double-clicking on something? Copy the XWin Server link on the start menu, and change the target of the copy from: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe to: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startx You probably want to change the name of the shortcut to something like XWin server (windowed) or whatever... Customize ~/.xinitrc to launch openbox by having it end 'exec openbox' and remove the line which starts twm. Double-click away! -- 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: How do I start WM?
On 23/02/2010 16:18, Christopher Faylor wrote: On 23/02/2010 14:11, Joseph Ess wrote: How do I start XWindows in full screen mode with OpenBox window manager? It used to be that I'd just put the command for the window manager at the end of startxwin.bat. Now that file's gone away. I can't use startxwin.exe as it is multi-window only. I can run XWin.exe, but the only command line or .XWinrc options I can find for that program are for Windows-specific functions(i.e. system tray icon). Read the documentation. http://x.cygwin.com/docs/ug/using.html#using-starting-startx -- Jon TURNEY Volunteer Cygwin/X X Server maintainer From: Jon TURNEYjon.tur...@dronecode.org.uk I've read the documentation. The page you refer to mentions startxwin and startx. As I mentioned before, startxwin is for multi-window only. startx apparently requires a Cygwin shell. I'm trying to start Cygwin/XWindows in full screen mode. Is there something I missed? From my reading of the documentation, it sounds like you'd get this behavior by adding server options to startxwin: startxwin -- [ server options ] This isn't actually the case, as startxwin always supplies the '-multiwindow' option to XWin, and there is no XWin option to specify the default (windowed) mode you can add after it. This is almost by design. There are a few differences between startx and startxwin, appropriate to running in windowed or multiwindow mode, and mixing them up would be a bad idea. * They use different scripts to start clients (~/.startxwinrc and ~/.xinitrc). This is because we expect the .xinitrc to end by starting a WM, which would a bad idea for .startxwinrc (as it would discover the internal WM is already running (hopefully)) and exit immediately. * startxwin exits after ~/.startxwinrc has completed and leaves XWin running, whereas startx waits until ~/.xinitrc exits (which is usually waiting for the WM started by it to exit) and then kills XWin. -- 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/
Get $100 to Starbucks or Dunkin Donuts
We hope you enjoyed receiving this email, but if you no longer wish to receive our emails please click here: http://bulldiety.net/aHR0cGQvZm9ybXMvN2JlZTQyNHUucGhwPzg4ODkmMzgyMTE1JnNiamlkPTM0MjY2JmludGlkPTYw -- 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/
Get $100 to Starbucks or Dunkin Donuts
We hope you enjoyed receiving this email, but if you no longer wish to receive our emails please click here: http://tvdiety.net/aHR0cGQvZm9ybXMvN2JlZTQyNHUucGhwPzg4ODkmMzgyMTE2JnNiamlkPTM0MjY2JmludGlkPTYw -- 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/
autogen.sh error
I'm trying to compile Xserver. Following the guide on http://x.cygwin.com/docs/cg/prog-obtaining-source.html, I tried to run autogen.sh and got errors. First, I got this error saying: configure.ac:42: error: must install xorg-macros 1.2 or later before running autoconf/autogen So I ran the cygwin setup again and obtained xorg-macros and ran autogensh again, then I got this: -- joffer...@dell ./autogen.sh -V autoreconf-2.65: Entering directory `.' autoreconf-2.65: configure.ac: not using Gettext autoreconf-2.65: running: aclocal --force -I m4 configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd /usr/share/aclocal/fontutil.m4:275: XORG_FONTROOTDIR is expanded from... configure.ac:84: the top level autoreconf-2.65: configure.ac: tracing configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:296: XORG_FONTROOTDIR is expanded from... configure.ac:84: the top level autoreconf-2.65: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd /usr/share/aclocal/fontutil.m4:275: XORG_FONTROOTDIR is expanded from... configure.ac:84: the top level autoreconf-2.65: running: /usr/bin/autoconf-2.65 --force configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:296: XORG_FONTROOTDIR is expanded from... configure.ac:84: the top level configure.ac:654: error: possibly undefined macro: XTRANS_CONNECTION_FLAGS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf-2.65: /usr/bin/autoconf-2.65 failed with exit status: 1 -- Can anyone tell me what's wrong? Thanks for your help. -- 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: autogen.sh error
On 24/02/2010 01:44, J. Offerman wrote: I'm trying to compile Xserver. Following the guide on http://x.cygwin.com/docs/cg/prog-obtaining-source.html, I tried to run autogen.sh and got errors. First, I got this error saying: configure.ac:42: error: must install xorg-macros 1.2 or later before running autoconf/autogen So I ran the cygwin setup again and obtained xorg-macros and ran autogensh again, then I got this: -- joffer...@dell ./autogen.sh -V autoreconf-2.65: Entering directory `.' autoreconf-2.65: configure.ac: not using Gettext autoreconf-2.65: running: aclocal --force -I m4 configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd I'd guess you don't have pkg-config installed? If so, you should go ahead and install everything mentioned on the previous page (http://x.cygwin.com/docs/cg/prog-build-prerequisites.html), you are going to need them all... -- 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: autogen.sh error
On Tue, Feb 23, 2010 at 6:19 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 24/02/2010 01:44, J. Offerman wrote: I'm trying to compile Xserver. Following the guide on http://x.cygwin.com/docs/cg/prog-obtaining-source.html, I tried to run autogen.sh and got errors. First, I got this error saying: configure.ac:42: error: must install xorg-macros 1.2 or later before running autoconf/autogen So I ran the cygwin setup again and obtained xorg-macros and ran autogensh again, then I got this: -- joffer...@dell ./autogen.sh -V autoreconf-2.65: Entering directory `.' autoreconf-2.65: configure.ac: not using Gettext autoreconf-2.65: running: aclocal --force -I m4 configure.ac:84: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd I'd guess you don't have pkg-config installed? If so, you should go ahead and install everything mentioned on the previous page (http://x.cygwin.com/docs/cg/prog-build-prerequisites.html), you are going to need them all... Thanks, there were others missing too. I have compiled Xserver on this machine before, I guess they've added new packages in the required list. With those packages installed now, I was able to compile XWin.exe and it is running fine. But I saw a couple of gcc errors saying -rdynamic is not a recognized option or something when the build process was building in hw/vfb and hw/xnest. I had to yank out those two directories from the build process by manually editing hw/Makefile. Can you help on this? -- 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/
src/winsup/utils ChangeLog locale.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-02-23 14:07:09 Modified files: winsup/utils : ChangeLog locale.cc Log message: * locale.cc (printlocale): Remove. (loc_t): New type to keep locale information for printing. (print_codeset): New function to print codeset as on Linux. (print_locale_with_codeset): New function to print single locale. Print verbose style as the Linux locale(1) tool. (print_locale): New function to print single locale plus its UTF-8 variation, if available. (compare_locales): New helper function for bsearch and qsort on loc_t. (add_locale): New function to store locale in loc_t array. (add_locale_alias_locales): New function to store locales from locale.alias file in loc_t. (print_all_locales): Call add_locale instead of printlocale. Call add_locale_alias_locales, sort locales alphabetically and print them. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.518r2=1.519 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/locale.cc.diff?cvsroot=srcr1=1.3r2=1.4
winsup/cygwin ChangeLog cygtls.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-02-24 00:03:42 Modified files: cygwin : ChangeLog cygtls.cc Log message: * cygtls.cc (_cygtls::init_exception_handler): Force installation of our exception handler to always be at the beginning. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4841r2=1.4842 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygtls.cc.diff?cvsroot=uberbaumr1=1.69r2=1.70
Re: terminfo [Re: console enhancements: mouse events etc]
On Tue, Feb 23, 2010 at 11:00:28AM +0100, Thomas Wolff wrote: Thomas Wolff wrote: Actually, I just remember again that I though I should change the terminfo entry too. Just - where's the source to patch? http://mirrors.kernel.org/sources.redhat.com/cygwin/release/terminfo/terminfo-5.7_20091114-13-src.tar.bz2 That -src package is basically just a wrapper around terminfo.src from ncurses-5.7 (as of patch level 20091114). So, the ultimate upstream source is actually ncurses. But I split it out specifically so that we could do faster updates of terminfo (rebuilding all of ncurses simply to change two characters in /usr/share/terminfo/[63|c]/cygwin is rather silly). So, send me patches against terminfo.src from that -src tarball, and once we've got it figured out, I'll push it upstream to the ncurses maintainer. Sorry for the slightly late response. Attached is a small patch. Wrong mailing list. cgf
Re: segmentation fault in /sbin/init from sysvinit package under 1.7.1
Dr. Volker Zell a écrit : Corinna Vinschen writes: Can you please try with the latest developer's snapshot? Chris has fixed a few issues with fifos since 1.7.1. Yep the latest snapshot (I only tested that one) fixed everything. I will provide an 1.7.1 version on sysvinit at the weekend which fixes the /bin/sh - /bin/bash bug in the /bin/init-config script. thanks, any release date for 1.7.2 ? if not a precise date, at least 1 week, 1 month, etc. ? :-) Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: Problems with mutt charset
On Sun, Feb 21, 2010 at 03:11:28PM +0100, Gary wrote: Sadly building mutt directly from the source package fails: make[2]: Entering directory `/usr/src/mutt-1.4.2.2-2/doc' ##test -f manual.html || make manual.html || cp ./manual*.html ./ cp ./manual*.html ./ cp: cannot stat `./manual*.html': No such file or directory make[2]: *** [try-html] Error 1 make[2]: Leaving directory `/usr/src/mutt-1.4.2.2-2/doc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/mutt-1.4.2.2-2' make: *** [install] Error 2 I see this was reported before, back in 2007 - http://www.mail-archive.com/cygwin@cygwin.com/msg82521.html - but there was never a solution posted. Anyone have any idea what is causing it? I'm assuming I should just be able to cd to /usr/src/mutt-1.4.2.2-2 and './configure' followed by 'make install'. Not really a solution, but Michael Elkins pointed out that this is only the html documentation, and the building of it can be disabled by editing the SUBDIRS variable in the makefile. See http://marc.info/?l=mutt-usersm=126685506502164w=2 I think the problem is the lack of sgml2html on Cygwin, but I am at a bit of a loss as to how the official package was built if that's the case. -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Tom, On Mon, Feb 22, 2010 at 10:48:14PM -0500, Thomas Baker wrote: Jason, On Mon, Feb 22, 2010 at 9:17 PM, Jason Tishler snip wrote: Please note the following: http://cygwin.com/acronyms#PPIOSPE My apologies if I overlooked that - I'm temporarily working in googlemail because of this procmail situation and feel out of my usual element (mutt). Unfortunately, you are still overlooking the above. :,( Procmail, on the other hand, is already set to VERBOSE and writes to a logfile procmail.log. On the netbook, where procmail works, it does write to the logfile. On the desktop, where procmail does not work, it does not write to the logfile, making me think it is somehow not even being called. What happens if you call procmail from the command line directly? Does it find your ~/.procmailrc file on the desktop machine? procmail -v does find $HOME/.procmailrc and /var/spool/mail/TBaker on the desktop machine. I meant running procmail from the command line with a mail message like the following: $ procmail foo.mail Does the above work on your desktop machine? Could case sensitivity be causing your problem (i.e., tbaker vs. TBaker)? What does the logname command and $HOME variable indicate on each machine? On the netbook: logname: tbaker $HOME is /home/tbaker On the desktop logname: TBaker $HOME is /home/tbaker I don't know why the case difference would cause a problem, but so far it is the only difference I can find between the two machines. If this problem came up only after an update to Cygwin 1.7, after working perfectly for years, is it possible that Cygwin is getting the logname from a different location now? Though I believe the logname on the desktop has been TBaker for years. AFAIK, no. This is drawing me deeper into the mechanics of mail than I ever thought I'd need to go. I'm still using Windows XP and wondering whether this might be the moment to take the plunge to Windows 7. Is it likely that starting with a clean install of Windows 7 and Cygwin might just make this problem go away? I thought that would be more work than de-bugging fetchmail/procmail, but now I'm not so sure. I don't know, but replacing the operating system seem like a very drastic way of solving this problem. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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
FIONREAD on ttyS0
Hi There ioctl(fd, FIONREAD, bytes) gives me errno 88 (fd is a handle on ttyS0). Is FIONREAD for serial tty not implemented? Greetz Stefan -- 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: FIONREAD on ttyS0
On Tue, Feb 23, 2010 at 03:04:48PM +0100, q0...@cuba.ionum.ch wrote: ioctl(fd, FIONREAD, bytes) gives me errno 88 (fd is a handle on ttyS0). Is FIONREAD for serial tty not implemented? From /usr/include/sys/errno.h: #define ENOSYS 88 /* Function not implemented */ So the answer is no it is not implemented. 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: terminfo [Re: console enhancements: mouse events etc]
On Tue, Feb 23, 2010 at 11:00:28AM +0100, Thomas Wolff wrote: Thomas Wolff wrote: Actually, I just remember again that I though I should change the terminfo entry too. Just - where's the source to patch? http://mirrors.kernel.org/sources.redhat.com/cygwin/release/terminfo/terminfo-5.7_20091114-13-src.tar.bz2 That -src package is basically just a wrapper around terminfo.src from ncurses-5.7 (as of patch level 20091114). So, the ultimate upstream source is actually ncurses. But I split it out specifically so that we could do faster updates of terminfo (rebuilding all of ncurses simply to change two characters in /usr/share/terminfo/[63|c]/cygwin is rather silly). So, send me patches against terminfo.src from that -src tarball, and once we've got it figured out, I'll push it upstream to the ncurses maintainer. Sorry for the slightly late response. Attached is a small patch. Wrong mailing list. Really? I thought it was a patch, even if to go upstream. And Charles had requested it on that list. No I wonder whether this is the right one... Thomas Ah, I see, sorry, another comment, those two lists are for cgwin dll only. However, the patch should have been attached with my cygwin dll patch in the first place, to be more proper, so I thought... and still Charles had requested it there... Thomas -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 8:13 AM, Jason wrote: http://cygwin.com/acronyms#PPIOSPE My apologies if I overlooked that - I'm temporarily working in googlemail because of this procmail situation and feel out of my usual element (mutt). Unfortunately, you are still overlooking the above. :,( Understand the principle now - correcting outgoing mail now by hand. I meant running procmail from the command line with a mail message like the following: $ procmail foo.mail Does the above work on your desktop machine? If I pipe one message into procmail with: procmail -v -d tbaker msg.mbox procmail reports: Locking strategies: dotlocking, fcntl() Default rcfile: $HOME/.procmailrc Your system mailbox:/var/spool/mail/TBaker and appends the message to the file /var/spool/mail/TBaker, ignoring the recipe in $HOME/.procmailrc. This also does not work: procmail -d tbaker msg.mbox However, on the netbook procmail -d tbaker msg.mbox works fine, delivering the message where it is supposed to go. Tom -- Tom Baker -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 10:33 AM, Thomas Baker wrote: This also does not work: procmail -d tbaker msg.mbox However, on the netbook procmail -d tbaker msg.mbox works fine, delivering the message where it is supposed to go. On the netbook the permissions for /usr/bin/procmail start with: -rwxr-x---+ but on the desktop the permissions lack the final +: -rwxr-x--- However, I do not see any obvious explanation in man chmod or the books I have on hand. Any chance this difference could be significant? Tom -- Tom Baker tba...@tbaker.de -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
According to Thomas Baker on 2/23/2010 9:06 AM: On the netbook the permissions for /usr/bin/procmail start with: -rwxr-x---+ The trailing + tells you that there are ACLs attached to the file that may further impact who can access the file. getfacl can show you those additional permissions; maybe it is a case where you were relying on an ACL. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 10:33:24AM -0500, Thomas Baker wrote: If I pipe one message into procmail with: procmail -v -d tbaker msg.mbox procmail reports: Locking strategies: dotlocking, fcntl() Default rcfile: $HOME/.procmailrc Your system mailbox:/var/spool/mail/TBaker and appends the message to the file /var/spool/mail/TBaker, ignoring the recipe in $HOME/.procmailrc. Oh. Actually I thought procmail was not suppose to deliver when given -v -v Procmail will print its version number, display its compile time configuration and exit. (from the man page) This also does not work: procmail -d tbaker msg.mbox Can you be a bit more specific? Is anything added to the procmail log? You could also add VERBOSE=on on the command line for more info. http://pm-doc.sourceforge.net/pm-tips.html recommends LOGFILE = $PMSRC/pm.log LOGABSTRACT = all VERBOSE = on in the .procmailrc. And you're sure you are running the correct procmail, i.e. there is no other procmail in your path before the one you are expecting to run? $ type -a procmail procmail is /usr/bin/procmail procmail is /bin/procmail -- 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
ssh problem using publickey in domain environment
I have read this mailing list and many other good pages how to setup sshd in cygwin environment. I have installed many sshd cygwin servers, but last some servers I have been publickey auth problem. Basic model works fine, but in the domain environment has been some problems. Today I found some answer, but not all. If I have used ex. win2003 (or win2008r2) servers and those are member of domain and domain controller then ssh-host-config -y net start sshd works fine, you can use password or rsa publickey auth, no problem. cyg_server and sshd are domain users, works fine. But if your server is member of domain, but not domain controller, then publickey not work, setsuid problem. In this case server can use local and domain users. Controller use only domain users. Today I found dirty solution, I added also local user and it works fine also with publickey auth. cyg_server and sshd are local users and user is also local, works fine. But not using domain users ? mkpasswd -l ... mkpasswd -d domain ... Why it works if your server is domain controller, but not if you have only member of domain ? - setting priviledges ? ex. SeAssignPrimaryTokenPrivilege If your server is member of domain, howto make users, sshd, (which order) ... without setuid problem when using publickey auth ? cyg_server and sshd - domain user or local or both, ??? -jukka- -- 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 SIGEMT under Cygwin
On 02/23/2010 01:41 AM, Paul McFerrin wrote: This question is for Larry Hall. Hi Paul. Actually, there are others on this list that could answer this question for you as well. Technically, a quick look at the code provides the answer. :-) Does signal SIGEMT mean anything under Cygwin? I have a Webserver process (httpd) that is terminating with a signal SIGEMT? When I looked at the code, I saw no use for SIGEMT. I'm assuming the signal is generated external to the process. That would have been my guess as well, given the nature of SIGEMT. But looking at the Cygwin DLL code, this signal is defined but not currently emitted. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Statically initialising pthread attributes in dynamic dlls.
On 23/02/2010 10:00, Andrew West wrote: With the code I'm testing against, the exception handler isn't called in the library and it bombs out there. :( The dll initialisation stuff calls '_cygtls::init_exception_handler' but it doesn't insert it because it finds it's already there ( from test.exe I guess ), or at least it doesn't hit my break point in '_cygtls::reset_fault' during the call to pthread_mutexattr_init. Further to this ( possibly instead of this ). When the code reaches this point inside the call to pthread_mutexattr_init; if ((*object)-magic != magic) Shouldn't the SEH contain the cytls exception handler as the first item in the list? I seem to have 4 things before it; (gdb) info w32 selector Selector $cs snip 0x03b: base=0x7ffdf000 limit=0x0fff 32-bit Data (Read/Write, Exp-up) snip (gdb) x/wx 0x7ffdf000 0x7ffdf000: 0x0022c628 (gdb) x/2wx 0x0022c628 0x22c628: 0x0022c8d4 0x7c90e920 (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022c8d4 0x22c8d4: 0x0022cb7c 0x7c90e920 (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022cb7c 0x22cb7c: 0x0022cbe4 0x7c90e920 (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022cbe4 0x22cbe4: 0x0022ce68 0x7c839ad8 (gdb) x/x 0x7c839ad8 0x7c839ad8 ValidateLocale+688:0x83ec8b55 (gdb) x/2wx 0x0022ce68 0x22ce68: 0x0022ffe0 0x61028d70 (gdb) x/x 0x61028d70 0x61028d70 _ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_listP8_CONTEXTPv: 0x57e58955 (gdb) x/2wx 0x0022ce68 0x22ce68: 0x0022ffe0 0x61028d70 (gdb) x/x 0x61028d70 0x61028d70 _ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_listP8_CONTEXTPv: 0x57e58955 (gdb) x/x 0x0022ffe0 0x22ffe0: 0x No idea if I'm even in the right area with this, or am I looking at this list in the wrong order... and should the cygtls exception handler really be in the list twice? Andy -- 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: ssh problem using publickey in domain environment
On 02/23/2010 12:01 PM, Jukka Inkeri wrote: If your server is member of domain, howto make users, sshd, (which order) ... without setuid problem when using publickey auth ? cyg_server and sshd - domain user or local or both, ??? In order for the SSH server to switch user context to a domain user, the service's user (cyg_server) must be a domain user with the rights outlined in 'ssh-host-config'. I'm not sure if it's a requirement that the 'sshd' user also be a domain user. I've never played with that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 11:25 AM, Eric wrote: According to Thomas Baker on 2/23/2010 9:06 AM: On the netbook the permissions for /usr/bin/procmail start with: -rwxr-x---+ The trailing + tells you that there are ACLs attached to the file that may further impact who can access the file. getfacl can show you those additional permissions; maybe it is a case where you were relying on an ACL. getfacl -a /usr/bin/procmail on the desktop says: # file: /usr/bin/procmail # owner: TBaker # group: Users user::rwx group::r-x mask:rwx other:--- On the netbook it has two additional permissions: # file: /usr/bin/procmail # owner: tbaker # group: Benutzer user::rwx group::r-x - group:root:rwx - group:SYSTEM:rwx mask:rwx other:--- A promising development...! How might I set those permissions on the desktop? Many thanks, Tom -- Tom Baker tba...@tbaker.de -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Tom, On Tue, Feb 23, 2010 at 05:49:27PM +0100, Gary wrote: On Tue, Feb 23, 2010 at 10:33:24AM -0500, Thomas Baker wrote: This also does not work: procmail -d tbaker msg.mbox Can you be a bit more specific? Is anything added to the procmail log? You could also add VERBOSE=on on the command line for more info. What does the following indicate? $ procmail VERBOSE=on msg.mbox Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 11:49 AM, Gary wrote: If I pipe one message into procmail with: procmail -v -d tbaker msg.mbox procmail reports: Locking strategies: dotlocking, fcntl() Default rcfile: $HOME/.procmailrc Your system mailbox: /var/spool/mail/TBaker and appends the message to the file /var/spool/mail/TBaker, ignoring the recipe in $HOME/.procmailrc. Oh. Actually I thought procmail was not suppose to deliver when given -v -v Procmail will print its version number, display its compile time configuration and exit. (from the man page) My mistake. It did just display and exit. The appended message was indeed from the next command I executed (below). This also does not work: procmail -d tbaker msg.mbox Can you be a bit more specific? Is anything added to the procmail log? You could also add VERBOSE=on on the command line for more info. http://pm-doc.sourceforge.net/pm-tips.html recommends LOGFILE = $PMSRC/pm.log LOGABSTRACT = all VERBOSE = on in the .procmailrc. I have had logs set up all along, and have now made them verbose. When I execute procmail -d tbaker test.mbox -- On the netbook, it gets correctly delivered by procmail and verbosely described in the log. -- On the desktop, the message gets appended to /var/spool/mail/TBaker, and nothing is written into the log. None of the tests I have done on the desktop have been recorded in the log. The same log directory exists on both machines - I have been using the same log filename for several years as the entire directory structure got passed back and forth between the two machines. Tom And you're sure you are running the correct procmail, i.e. there is no other procmail in your path before the one you are expecting to run? $ type -a procmail procmail is /usr/bin/procmail procmail is /bin/procmail -- 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 -- Tom Baker tba...@tbaker.de -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
And you're sure you are running the correct procmail, i.e. there is no other procmail in your path before the one you are expecting to run? $ type -a procmail procmail is /usr/bin/procmail procmail is /bin/procmail Yes, though the result repeats itself as follows: $ type -a procmail procmail is /usr/bin/procmail procmail is /bin/procmail procmail is /usr/bin/procmail procmail is /bin/procmail ...just in case that is significant... Tom -- Tom Baker tba...@tbaker.de -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 1:28 PM, Jason wrote: Can you be a bit more specific? Is anything added to the procmail log? You could also add VERBOSE=on on the command line for more info. What does the following indicate? $ procmail VERBOSE=on msg.mbox procmail: [4092] Tue Feb 23 14:11:50 2010 procmail: Locking /var/spool/mail/TBaker.lock procmail: Assigning LASTFOLDER=/var/spool/mail/TBaker procmail: Opening /var/spool/mail/TBaker procmail: Acquiring kernel-lock procmail: Unlocking /var/spool/mail/TBaker.lock procmail: Notified comsat: tba...@21429:/var/spool/mail/TBaker From tba...@tbaker.de Sat Feb 20 16:47:32 2010 Subject: TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST Folder: /var/spool/mail/TBaker542 Tom -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Tom, On Tue, Feb 23, 2010 at 02:14:00PM -0500, Thomas Baker wrote: On Tue, Feb 23, 2010 at 1:28 PM, Jason wrote: Can you be a bit more specific? Is anything added to the procmail log? You could also add VERBOSE=on on the command line for more info. What does the following indicate? ?? ??$ procmail VERBOSE=on msg.mbox procmail: [4092] Tue Feb 23 14:11:50 2010 procmail: Locking /var/spool/mail/TBaker.lock [snip] You should have seen a line like the following: procmail: Rcfile: /home/TBaker/.procmailrc between the above two lines. For some reason, procmail is not finding your $HOME/.procmailrc file. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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
[ANNOUNCEMENT] Updated: rsync-3.0.7-1
Version 3.0.7-1 of rsync has been uploaded. rsync is a file transfer program. rsync uses the 'rsync algorithm' which provides a very fast method for bringing remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand. This release include (experimental) support for xattr which should work correctly on SMB shares and NTFS drives. If you're not sure what version do you have you can use the following command to both check version number and integrity of the install: % cygcheck -c rsync If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** 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=yourdomain@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. -- Lapo Luchini “I think, therefore I am… I think.” (Nordom, videogame Torment, 1999) -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 2:35 PM, Jason Tishler wrote: What does the following indicate? ?? ??$ procmail VERBOSE=on msg.mbox procmail: [4092] Tue Feb 23 14:11:50 2010 procmail: Locking /var/spool/mail/TBaker.lock [snip] You should have seen a line like the following: procmail: Rcfile: /home/TBaker/.procmailrc between the above two lines. For some reason, procmail is not finding your $HOME/.procmailrc file. This is what I find...: $ cd /home $ ls Administrator TBaker tbaker $ find TBaker TBaker TBaker/.bashrc TBaker/.bash_history TBaker/.bash_profile TBaker/.inputrc $ In other words, all of my files are in /home/tbaker except for the new bash configuration files, which are (the only) files in /home/TBaker. When I upgraded to Cygwin 1.7, I now vaguely recall seeing a message about creating new .bashrc files when I first ran the shell. If I rename 'TBaker' to 'foobar' (to take it out of action) and re-run...: $ procmail VERBOSE=on test.mbox procmail: [3240] Tue Feb 23 14:59:34 2010 procmail: Locking /var/spool/mail/TBaker.lock procmail: Assigning LASTFOLDER=/var/spool/mail/TBaker procmail: Opening /var/spool/mail/TBaker procmail: Acquiring kernel-lock procmail: Unlocking /var/spool/mail/TBaker.lock procmail: Notified comsat: tba...@22513:/var/spool/mail/TBaker From tba...@tbaker.de Sat Feb 20 16:47:32 2010 Subject: TEST TEST TEST TEST TEST TEST TEST TEST TEST Folder: /var/spool/mail/TBaker 542 Evidently if it does not find /home/TBaker/.procmailrc, it does not go looking for /home/tbaker/.procmailrc. Since my entire file system is based on tbaker, I'd love to find a way to eradicate the TBaker from my system entirely. The guy who set up my XP installation many years ago set my login as TBaker but it has never caused any practical problems until now. Tom -- Tom Baker tba...@tbaker.de -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Evidently if it does not find /home/TBaker/.procmailrc, it does not go looking for /home/tbaker/.procmailrc. Since my entire file system is based on tbaker, I'd love to find a way to eradicate the TBaker from my system entirely. The guy who set up my XP installation many years ago set my login as TBaker but it has never caused any practical problems until now. This worked: $ cd /home $ cp tbaker/.procmailrc TBaker $ procmail VERBOSE=on test.mbox procmail: [3528] Tue Feb 23 15:22:39 2010 procmail: Rcfile: /home/TBaker/.procmailrc procmail: Assigning MAILDIR=/home/TBaker procmail: Assigning INCLUDERC=/home/tbaker/u/config/procmailrc/procmailrc procmail: Assigning LOG= procmail: Assigning VERBOSE=on procmail: Assigning LOGABSTRACT=all procmail: Assigning MAILDIR=/home/tbaker/u/folders procmail: Assigning DEFAULT=/home/tbaker/u/folders/mbox procmail: Assigning PMDIR=/home/tbaker/u/config/procmailrc procmail: Assigning LOGFILE=/home/tbaker/u/config/procmailrc/procmail.log procmail: Opening /home/tbaker/u/config/procmailrc/procmail.log $ In a pinch, it looks like this would solve the problem, but it is an ugly workaround. It would be nicer to expunge any references to TBaker entirely. I guess they are in the Win32 registry? I do not find any in my cygwin configuration files. Hang on... There it is in /etc/passwd...: TBaker:unused_by_nt/2000/xp:1003:513:U-OCTAVIUS\TBaker,S-[...omitted...]:/home/TBaker:/bin/bash and /etc/passwd was last accessed on 2007-11-16, so it would seem procmail _was_ able to work with this before the latest update -- if indeed /etc/passwd has anything to do with procmail's operation... Tom -- Tom Baker tba...@tbaker.de -- 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
cygwin + rsync issue under Windows 7 x64
Friends -- I am posting this to both lists since I think it has to do with some kind of unfortunate interaction. The latest rsync (3.0.7-1) under an up-to-date cygwin on Windows 7 x64 gets into some kind of busy wait situation when transferring large files over ssh. rsync, ssh, and zip can all be consuming much cpu time. I downloaded and built rsync 3.0.7 locally, manually editing config.status to turn off HAVE_SOCKETPAIR. The resulting rsync works fine. So, what specific diagnosis and further information would you find most helpful? A few months ago, Corinna and I went through a whole round of trying to get socketpair to work better, and she developed a BLODA work-around. At her request, I have kept the particular offending BLODA installed. AFAIK, the original problem (complete inability to open a socketpair and fork properly) is gone. This is a different problem, but seems to have to do with not being able to push data through socket pairs or detect presence of more data, etc. Regards -- Eliot Moss -- 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: Statically initialising pthread attributes in dynamic dlls.
On 23/02/2010 17:28, Andrew West wrote: Further to this ( possibly instead of this ). When the code reaches this point inside the call to pthread_mutexattr_init; if ((*object)-magic != magic) Shouldn't the SEH contain the cytls exception handler as the first item in the list? I seem to have 4 things before it; I think the OS has wrapped the call to DllMain in its own handler that gets in ahead of cygwin's. When the pthread_mutex stuff throws during validating the verifyable object, the OS catches it, says oops! there's been an exception during DllMain, this DLL is faulty and unmaps it. Then LoadLibraryW returns an error status to dlopen, but the problem is that there's an unpopped return address on the tls sigfe stack, and when dlopen tries to return it jumps into that (now unmapped) space. cheers, DaveK -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On 02/23/2010 03:37 PM, Thomas Baker wrote: Evidently if it does not find /home/TBaker/.procmailrc, it does not go looking for /home/tbaker/.procmailrc. Since my entire file system is based on tbaker, I'd love to find a way to eradicate the TBaker from my system entirely. The guy who set up my XP installation many years ago set my login as TBaker but it has never caused any practical problems until now. He should still be shot. ;-) This worked: $ cd /home $ cp tbaker/.procmailrc TBaker $ procmail VERBOSE=ontest.mbox procmail: [3528] Tue Feb 23 15:22:39 2010 procmail: Rcfile: /home/TBaker/.procmailrc procmail: Assigning MAILDIR=/home/TBaker procmail: Assigning INCLUDERC=/home/tbaker/u/config/procmailrc/procmailrc procmail: Assigning LOG= procmail: Assigning VERBOSE=on procmail: Assigning LOGABSTRACT=all procmail: Assigning MAILDIR=/home/tbaker/u/folders procmail: Assigning DEFAULT=/home/tbaker/u/folders/mbox procmail: Assigning PMDIR=/home/tbaker/u/config/procmailrc procmail: Assigning LOGFILE=/home/tbaker/u/config/procmailrc/procmail.log procmail: Opening /home/tbaker/u/config/procmailrc/procmail.log $ In a pinch, it looks like this would solve the problem, but it is an ugly workaround. Yeah, I wouldn't go that far when a symbolic link to /home/tbaker would suffice. It would be nicer to expunge any references to TBaker entirely. I guess they are in the Win32 registry? I do not find any in my cygwin configuration files. Hang on... There it is in /etc/passwd...: TBaker:unused_by_nt/2000/xp:1003:513:U-OCTAVIUS\TBaker,S-[...omitted...]:/home/TBaker:/bin/bash and /etc/passwd was last accessed on 2007-11-16, so it would seem procmail _was_ able to work with this before the latest update -- if indeed /etc/passwd has anything to do with procmail's operation... http://cygwin.com/cygwin-ug-net/ov-new1.7.html Changing the user name in '/etc/passwd' to use the proper case should resolve the problem though. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Cygwin build scripts in perl
(a) I found that winsup/cygwin/mkimport specified non-existent file names as
arguments to objcopy invocations. I am not sure why this did not cause build
breaks earlier.
(b) It appears perl 5.6 and, possibly, perl 5.10 do not implement the list
form of pipe in calls to open(),
open $my_fd, '-|', $cmd, $arg1, $arg2
I got around that by using regular pipes.
(c) The Windows native build of perl wrapped into a cygpath-translating script
/usr/bin/perl will require protection of drive letters when using a regex in
speclib. I believe this change may still work with Cygwin builds of perl.
I am not aware of the purpose of the two scripts that I modified, but the fixes
made my build succeed.
--
==
$ cat /usr/bin/perl
#! /bin/bash
args=()
for f ; do
if [ -f ${f} ] ; then
f=$(cygpath -w ${f})
f=${f#\?\\}
fi
args+=(${f})
done
set -x
exec /c/NATIVEPERL/perl.exe -Ic:/NATIVEPERL/lib ${ar...@]}
==Index: speclib
===
RCS file: /cvs/src/src/winsup/cygwin/speclib,v
retrieving revision 1.24
diff -d -u -r1.24 speclib
--- speclib 30 Nov 2009 15:40:23 - 1.24
+++ speclib 23 Feb 2010 23:18:37 -
@@ -13,7 +13,7 @@
my ($ar, $as, $nm, $objcopy);
GetOptions('exclude=s'=\...@exclude, 'static!'=\$static, 'v!'=\$inverse,
- 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy);
+ 'ar=s'=\$ar, 'as=s'=\$as,'nm=s'=\$nm, 'objcopy=s'=\$objcopy);
$_ = File::Spec-rel2abs($_) for @ARGV;
@@ -22,8 +22,11 @@
(my $iname = basename $lib) =~ s/\.a$//o;
$iname = '_' . $iname . '_dll_iname';
-open my $nm_fd, '-|', $nm, '-Apg', '--defined-only', @ARGV, $libdll or
- die $0: execution of $nm for object files failed - $!\n;
+my $qargs = join( , map(\$_\, @ARGV));
+my $cmd_nm = $nm -Apg --defined-only $qargs \$libdll\;
+print Reading from $cmd_nm ...\n;
+open my $nm_fd, $cmd_nm | or
+ die E: $0: $cmd_nm:\n$!\n;
my %match_syms = ();
my $symfiles = ();
@@ -35,44 +38,47 @@
while ($nm_fd) {
study;
if (/ I _(.*)_dll_iname/o) {
- $dllname = $1;
+$dllname = $1;
} else {
- my ($file, $member, $symbol) = m%^([^:]*):([^:]*(?=:))?.* T (.*)%o;
- next if !defined($symbol) || $symbol =~ $exclude_regex;
- if ($file ne $libdll) {
-$match_syms{$symbol} = 1;
-} elsif ($match_syms{$symbol} ? !$inverse : $inverse) {
-$extract{$member} = 1;
-}
+my ($file, $member, $symbol) = m%^(.*?(?!:\\)):([^:]*:)?[0-9a-fA-F]{8}
T (.*)%o;
+next if !defined($symbol) || $symbol =~ $exclude_regex;
+if ($file ne $libdll) {
+$match_syms{$symbol} = 1;
+} elsif ($match_syms{$symbol} ? !$inverse : $inverse) {
+chop($member);
+$extract{$member} = 1;
+}
}
}
close $nm_fd;
-
-%extract or die $0: couldn't find symbols for $lib\n;
+%extract or die E: $0: couldn't find symbols for $lib\n;
my $dir = tempdir(CLEANUP = 1);
chdir $dir;
# print join(' ', '+', $ar, 'x', sort keys %extract), \n;
my $res = system $ar, 'x', $libdll, sort keys %extract;
-die $0: $ar extraction exited with non-zero status\n if $res;
+die E: $0: $ar extraction exited with non-zero status\n if $res;
unlink $lib;
# Add a dummy .idata object for libtool so that it will think
# this library is an import library.
my $iname_o = 'd00.o';
$extract{$iname_o} = 1;
-open my $as_fd, '|-', $as, '-R', '-o', $iname_o, -;
+my $cmd_as = $as -R -o $iname_o -;
+print Writing to $cmd_as ...\n;
+open my $as_fd, | $cmd_as or die E: $0: $cmd_as:\n$!\n;
print $as_fd EOF;
- .section .idata\$7
+.section .idata\$7
.global $iname
$iname: .asciz $dllname.dll
EOF
close $as_fd or exit 1;
-system $objcopy, '-j', '.idata$7', $iname_o;
+system $objcopy, '-j', '.idata$7', $iname_o and die E: $0: $objcopy:\n$!\n;
$res = system $ar, 'crus', $lib, sort keys %extract;
unlink keys %extract;
-die $0: ar creation of $lib exited with non-zero status\n if $res;
+die E: $0: ar creation of $lib exited with non-zero status\n if $res;
exit 0;
+
Index: speclib
===
RCS file: /cvs/src/src/winsup/cygwin/speclib,v
retrieving revision 1.24
diff -d -u -w -r1.24 speclib
--- speclib 30 Nov 2009 15:40:23 - 1.24
+++ speclib 23 Feb 2010 23:18:32 -
@@ -22,8 +22,11 @@
(my $iname = basename $lib) =~ s/\.a$//o;
$iname = '_' . $iname . '_dll_iname';
-open my $nm_fd, '-|', $nm, '-Apg', '--defined-only', @ARGV, $libdll or
- die $0: execution of $nm for object files failed - $!\n;
+my $qargs = join( , map(\$_\, @ARGV));
+my $cmd_nm = $nm -Apg --defined-only $qargs \$libdll\;
+print Reading from $cmd_nm ...\n;
+open my $nm_fd, $cmd_nm | or
+ die E: $0: $cmd_nm:\n$!\n;
my %match_syms = ();
my $symfiles = ();
@@ -37,42 +40,45
Re: Statically initialising pthread attributes in dynamic dlls.
On Tue, Feb 23, 2010 at 05:28:06PM +, Andrew West wrote: On 23/02/2010 10:00, Andrew West wrote: With the code I'm testing against, the exception handler isn't called in the library and it bombs out there. :( The dll initialisation stuff calls '_cygtls::init_exception_handler' but it doesn't insert it because it finds it's already there ( from test.exe I guess ), or at least it doesn't hit my break point in '_cygtls::reset_fault' during the call to pthread_mutexattr_init. Further to this ( possibly instead of this ). When the code reaches this point inside the call to pthread_mutexattr_init; if ((*object)-magic != magic) Shouldn't the SEH contain the cytls exception handler as the first item in the list? I seem to have 4 things before it; (gdb) info w32 selector Selector $cs snip 0x03b: base=0x7ffdf000 limit=0x0fff 32-bit Data (Read/Write, Exp-up) snip (gdb) x/wx 0x7ffdf000 0x7ffdf000: 0x0022c628 (gdb) x/2wx 0x0022c628 0x22c628: 0x0022c8d4 0x7c90e920 FYI, there's a better way to look at these: set $el=(exception_list**)0x7ffdf000 print **$el print *($el-prev) (and I suspect there's an even better way to decode $fs:0 that I've forgotten) (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022c8d4 0x22c8d4: 0x0022cb7c 0x7c90e920 (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022cb7c 0x22cb7c: 0x0022cbe4 0x7c90e920 (gdb) x/x 0x7c90e920 0x7c90e920 strchr+275:0x83ec8b55 (gdb) x/2wx 0x0022cbe4 0x22cbe4: 0x0022ce68 0x7c839ad8 (gdb) x/x 0x7c839ad8 0x7c839ad8 ValidateLocale+688:0x83ec8b55 (gdb) x/2wx 0x0022ce68 0x22ce68: 0x0022ffe0 0x61028d70 (gdb) x/x 0x61028d70 0x61028d70 _ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_listP8_CONTEXTPv: 0x57e58955 (gdb) x/2wx 0x0022ce68 0x22ce68: 0x0022ffe0 0x61028d70 (gdb) x/x 0x61028d70 0x61028d70 _ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_listP8_CONTEXTPv: 0x57e58955 (gdb) x/x 0x0022ffe0 0x22ffe0: 0x No idea if I'm even in the right area with this, or am I looking at this list in the wrong order... and should the cygtls exception handler really be in the list twice? I never saw the cygwin exception handler on the list twice when I was debugging this. That isn't supposed to happen and I don't see how it could happen unless Windows is doing it since the code in _cygtls::init_exception_handler is supposed to prevent that and, if it was on the list twice bad stuff happened. That actually looks like a typo above since you seem to have typed the same address twice. Anyway, I've revisited this code, just like I knew I would, and have added YA in a long series of tweaks which seems to fix your particular problem. The fix is in the latest snapshot. Thanks for checking into this so deeply and thanks for the simple test case. 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: perl panics with cygwin snapshot
On Tue, Feb 23, 2010 at 06:11:17AM +, Shaddy Baddah wrote: This might be related to http://www.cygwin.com/ml/cygwin/2008-11/msg00021.html, I'm also seeing perl fail with a panic *with the latest snapshot*. Eg.: It's very unlikely that a 1+ year old email thread would have anything to do with a recent change to a cygwin snapshot. $ uname -a CYGWIN_NT-6.1 ***-w7 1.7.2s(0.222/5/3) 20100222 16:51:26 i686 Cygwin $ /bin/autom4te-2.65 --help panic: MUTEX_UNLOCK (1) [util.c:2641] at /bin/autom4te-2.65 line 93. Unlike that previous email, I have not tried to downgrade. I also cannot kill the associated perl process: This should be fixed in the latest snapshot, or at least, I can't reproduce it with the simple case above. 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: perl panics with cygwin snapshot
Hi, On 24/02/2010 12:46 AM, Christopher Faylor wrote: On Tue, Feb 23, 2010 at 06:11:17AM +, Shaddy Baddah wrote: This might be related to http://www.cygwin.com/ml/cygwin/2008-11/msg00021.html, I'm also seeing perl fail with a panic *with the latest snapshot*. Eg.: It's very unlikely that a 1+ year old email thread would have anything to do with a recent change to a cygwin snapshot. Yeah, it was a long shot, but included it just in case. $ uname -a CYGWIN_NT-6.1 ***-w7 1.7.2s(0.222/5/3) 20100222 16:51:26 i686 Cygwin $ /bin/autom4te-2.65 --help panic: MUTEX_UNLOCK (1) [util.c:2641] at /bin/autom4te-2.65 line 93. Unlike that previous email, I have not tried to downgrade. I also cannot kill the associated perl process: This should be fixed in the latest snapshot, or at least, I can't reproduce it with the simple case above. Yes, this seems to have fixed it. Thanks, Shaddy -- 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: terminfo [Re: console enhancements: mouse events etc]
Redirected to the cygwin list. Thomas Wolff wrote: Charles Wilson wrote: Thomas Wolff wrote: Actually, I just remember again that I though I should change the terminfo entry too. Just - where's the source to patch? So, send me patches against terminfo.src from that -src tarball, and once we've got it figured out, I'll push it upstream to the ncurses maintainer. Sorry for the slightly late response. Attached is a small patch. Two notes: * I used the occasion to add PC graphics mode to the linux console, too, which have always been missing there. I'm not sure about this. The only situation where you'd be using the cygwin terminfo database while interacting with a linux console is if you were running a cygwin shell, under WINE, from a console mode linux login. Or maybe if you were remotely accessing a cygwin box from a console mode linux session. However, in both cases, the terminal description would DIFFER from the one the actual linux box, the one you'd be sitting in front of, uses. This sounds like trouble to me. I think the better approach -- doomed to rejection, unfortunately (*) -- is to submit this change directly upstream to ncurses (Thomas Dickey). If it's picked up there, then it will filter down thru the linux distributions, AND we'll get it. (*) Thomas (Dickey) has a policy of accepting terminal description changes ONLY from the maintainers of the emulator/console code: e.g. konsole from the KDE devs, linux from lkml only, etc. He's unlikely to accept a patch to the linux terminfo description from us. But, give it a try anyway... * I patched cygwinDBG only for now, because if the patch goes upstream, the new VT100 graphics mode will not be available for remote login from an older cygwin console for a while. Feel free to modify the entry cygwin accordingly if you feel confident with it. No, I think it would be best to update cygwin itself (and maybe cygwinDBG. Anybody use that?) If we want to add cygwin-old (cygwin-1p5? suggestion for a better name?) for backwards compatibility, we can. But the current cygwin terminal description should describe the current cygwin terminal capabilities. BTW, does this fix 'pstree -G'? I'll adapt and release an update relatively soon. Thanks for your efforts, Thomas (Wolff). Apologies, all, for the confusion about mailing lists. My fault; I suggested Thomas send a patch during a conversation on the the -developers list. I forgot to specify /where/ it should have been sent. Sorry. -- Chuck -- 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
[ANNOUNCEMENT] Updated: Unicode text editor MinEd 2000.16
MinEd 2000.16 (Feb 2010) This release of MinEd introduces two major new features for which it is a beta release and I would especially appreciate comments on them: * Self-made interactive selection highlighting, meaning: - Mouse selection highlighting now works in other terminals than just xterm, including the cygwin console (from cygwin 1.7.2). - Selection highlighting is also applied for keyboard selection. A few options are offered to tune selection highlighting; open the Paste buffer menu (from the Options menu or the %= flags) and choose options in the visual selection section. - Del key changed: With new selection highlighting, the function of the Del keypad key could finally be changed to meet more common user expectations (dual-mode behaviour): if a visual selection is active, delete it, otherwise delete next character. * Rectangular copy and paste. - Applying interactive rectangular selection highlighting. Both cygwin releases (the cygwin package and the Windows stand-alone package) register MinEd for invocation from the Windows Explorer context menu for text files. Summary of major enhancements in this release (if relevant for cygwin): Text editing features: * New rectangular copy/paste area mode. * Enhanced smart quotes algorithm and input support for apostrophe. * Support fow Hawai'ian input. Interactive: * Self-made visual selection highlighting, supporting all terminals. * Changed Del keypad key to more common behaviour. * Calculated dim attribute for line markers in xterm and mintty. * Menu navigation: On a submenu entry, cursor-right enters the submenu too. File handling: * The text position is now more easily remembered. Interworking: * For cygwin: * Fixed creation of inter-window paste buffer in case hard link does not work (on FAT or network drives). * Enabled mouse navigation without button pressed for cygwin (1.7.2) console. * With cygwin 1.7.2, mouse interaction will be enhanced. * For mintty/cygwin: * Various tuning measures to make optimal use of this fine terminal. * The mined scrollbar is now enabled by default. (For right-to-left text editing, reduce visual confusion with -o.) Mined is a powerful text editor with a comprehensive yet concise and easy-to-use user interface supporting modern interaction paradigms, and fast, small-footprint behaviour. Mined provides both extensive Unicode and CJK support offering many specific features and covering special cases that other editors are not aware of (like auto-detection features and automatic handling of terminal variations, or Han character information). It was the first editor that supported Unicode in a plain-text terminal (like xterm or rxvt). Basically, mined is an editor tailored to reliable and efficient editing of plain text documents and programs, with features and interactive behaviour designed for this purpose. To install mined on cygwin, run the cygwin setup program, in the Select Packages menu, open the Editors category and select the mined package. More information (with screenshots, feature overview and change log) and download are available from the mined web site at http://towo.net/mined/ Mined is co-hosted at sourceforge and has a mailing list which can be subscribed at https://lists.sourceforge.net/lists/listinfo/mined-editor Thomas Wolff mi...@towo.net -- 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: Statically initialising pthread attributes in dynamic dlls.
On 24/02/2010 00:44, Christopher Faylor wrote: I never saw the cygwin exception handler on the list twice when I was debugging this. That isn't supposed to happen and I don't see how it could happen unless Windows is doing it since the code in _cygtls::init_exception_handler is supposed to prevent that and, if it was on the list twice bad stuff happened. That actually looks like a typo above since you seem to have typed the same address twice. Anyway, I've revisited this code, just like I knew I would, and have added YA in a long series of tweaks which seems to fix your particular problem. The fix is in the latest snapshot. :( I think I can see where the next problem is going to arise already. If we move el to the front of the list each time, what's going to happen when we eventually return from LoadLibrary, and el.prev is still pointing at the now-deallocated stack frames where LoadLibrary created its temporary EXCEPTION_REGISTRATION structures ? I was thinking of adding a stack (possibly only two-level) instead of relinking the single el member to the front, but either way we have to find some way to unlink it again when the stack unwinds. cheers, DaveK -- 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: terminfo [Re: console enhancements: mouse events etc]
Charles Wilson wrote: I'll adapt and release an update relatively soon. Thanks for your efforts, Thomas (Wolff). I'm guessing that these terminfo changes need to wait until 1.7.2, right? -- Chuck -- 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: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
On Tue, Feb 23, 2010 at 4:44 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Evidently if it does not find /home/TBaker/.procmailrc, it does not go looking for /home/tbaker/.procmailrc. Since my entire file system is based on tbaker, I'd love to find a way to eradicate the TBaker from my system entirely. The guy who set up my XP installation many years ago set my login as TBaker but it has never caused any practical problems until now. He should still be shot. ;-) Maybe along with the IBM guy who swapped Ctrl with CapsLock :-) Yeah, I wouldn't go that far when a symbolic link to /home/tbaker would suffice. Yes indeed! $ cd /home $ mv TBaker TBaker.bak $ ln -s /home/tbaker TBaker Now everything works fine again! :-) It would be nicer to expunge any references to TBaker entirely. I guess they are in the Win32 registry? I do not find any in my cygwin configuration files. I guess that's unnecessary now... http://cygwin.com/cygwin-ug-net/ov-new1.7.html Yes, I had indeed scanned through that bulletin but didn't see this one coming, if it was indeed a 1.7 update issue at all. I guess the issues around the missing APLs (see above): group:root:rwx group:SYSTEM:rwx turned out to be irrelevant? Changing the user name in '/etc/passwd' to use the proper case should resolve the problem though. $ vim /etc/passwd has apparently fixed everything. Much easier than migrating my whole system from XP to Windows 7. Thank you, all, for your patience and attention to detail! :-) Tom -- Tom Baker -- 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
Max no of parallel SSH sessions with Cygwin SSHD
Hello All, I am trying to use Cygwin SSHD in my project. I have defined a subsystem under SSHD which gets accessed by the client. Each subsystem invocation spawns 3 processes (1 sshd + 1sh + 1 tclsh). I have observed that on WinXP only 22 parallel sessions are possible whereas on a Win2k3 server 48 parallel sessions are possible. Both are of a similar hardware configuration (3Ghz CPU, 2GB RAM). After which it seems like some resource allocation limit is reached, though there is a lot more Memory and CPU available. I have tried increasing the heap allocation but it does not help the situation. 1. My question is that why is there a difference between the 2 OSs ? 2. Does XP have resource allocation lower limits than win2k3 server ? 3. How can this be overcome ? (some OS settings ..) -- Regards, Girish. S. Sadhani -- 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: Statically initialising pthread attributes in dynamic dlls.
On 24/02/2010 01:39, Dave Korn wrote: On 24/02/2010 00:44, Christopher Faylor wrote: Anyway, I've revisited this code, just like I knew I would, and have added YA in a long series of tweaks which seems to fix your particular problem. The fix is in the latest snapshot. :( I think I can see where the next problem is going to arise already. If we move el to the front of the list each time, what's going to happen when we eventually return from LoadLibrary, and el.prev is still pointing at the now-deallocated stack frames where LoadLibrary created its temporary EXCEPTION_REGISTRATION structures ? Confirmed. Here's the SEH chain at the call to pthread_mutexattr_init: (gdb) x/xw 0x7ffde000 0x7ffde000: 0x0022ce68 (gdb) x/2xw 0x0022ce68 0x22ce68: 0x0022c8b4 0x61028d70 (gdb) x/2xw 0x0022c8b4 0x22c8b4: 0x0022cb4c 0x77fb7e64 (gdb) x/2xw 0x0022cb4c 0x22cb4c: 0x0022cbf8 0x77fb7e64 (gdb) x/2xw 0x0022cbf8 0x22cbf8: 0x0022ffe0 0x7c5c2160 (gdb) x/2xw 0x0022ffe0 0x22ffe0: 0x 0x7c5c2160 (gdb) print $esp $1 = (void *) 0x22c764 At this point, the call stack looks roughly like main - dlopen - LoadLibraryW - DllMain - dll_dllcrt0_1 - dll::init (because the cygwin dll is already initialised, we don't defer calling) - dll static ctors - Mutex::Mutex - pthread_mutexattr_init. After this, we return from the Mutex ctor, dll::init calls DllMain and then returns back to the OS loader code which eventually returns via the tail of LoadLibrary and dlopen to main: (gdb) c Continuing. Breakpoint 6, main (argc=1, argv=0x659e18) at test.cpp:6 6 dlclose( dll ); (gdb) print $esp $2 = (void *) 0x22cd00 (gdb) x/xw 0x7ffde000 0x7ffde000: 0x0022ffe0 (gdb) x/2xw 0x0022ffe0 0x22ffe0: 0x 0x7c5c2160 (gdb) Our EH got uninstalled when the OS uninstalled its own handlers! That makes sense of course: when a function that has instantiated an EXCEPTION_REGISTRATION record in automatic stack storage returns, it's just going to assume that any deeper ones have already been unwound and look at its own prev pointer and just set the head of the eh chain there. I think the answer lies here, in this comment in dll_dllcrt0_1: /* Make sure that our exception handler is installed. That should always be the case but this just makes sure. At some point, we may want to just remove this code since the exception handler should be guaranteed to be installed. I'm leaving it in until potentially after the release of 1.7.1 */ _my_tls.init_exception_handler (_cygtls::handle_exceptions); Well, it may or may not already be installed, depending whether we got here via dlopen or whether this is a statically-linked DLL being initialised at process startup, and if it is already installed, it's not at the front of the list. So I figure the best bet would be to replace this call with a local stack-frame-based exception registration record, which we'll unlink if we return. IOW, just the same thing as those OS-registered SEH frames are doing when they unwind. I'll report back later if it works. cheers, DaveK -- 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: Statically initialising pthread attributes in dynamic dlls.
On 24/02/2010 04:52, Dave Korn wrote:
I think the answer lies here, in this comment in dll_dllcrt0_1:
/* Make sure that our exception handler is installed.
That should always be the case but this just makes sure.
At some point, we may want to just remove this code since
the exception handler should be guaranteed to be installed.
I'm leaving it in until potentially after the release of
1.7.1 */
_my_tls.init_exception_handler (_cygtls::handle_exceptions);
Well, it may or may not already be installed, depending whether we got here
via dlopen or whether this is a statically-linked DLL being initialised at
process startup, and if it is already installed, it's not at the front of the
list. So I figure the best bet would be to replace this call with a local
stack-frame-based exception registration record, which we'll unlink if we
return. IOW, just the same thing as those OS-registered SEH frames are doing
when they unwind. I'll report back later if it works.
Yeh, that works nicely. Here's what I tested, along with a couple of extra
test cases I used to check whether exception handling was still working before
and after the dlopen call. With the current state of HEAD, the first one
works (by which I mean prints 'sig 11' forever and the second one fails (by
which I means reaches some sort of exit without hitting the signal handler at
all). With the attached diff, they both work (as does the original unmodified
testcase).
This is just a brain dump because I'm off to bed now, hence no change log,
and there's still commented-out stuff and inadequate commenting, but I figured
I may as well let everyone know what I found out. 'night all!
cheers,
DaveK
Index: winsup/cygwin/dll_init.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dll_init.cc,v
retrieving revision 1.70
diff -p -u -r1.70 dll_init.cc
--- winsup/cygwin/dll_init.cc 5 Feb 2010 15:05:22 - 1.70
+++ winsup/cygwin/dll_init.cc 24 Feb 2010 05:05:45 -
@@ -329,7 +329,14 @@ dll_dllcrt0_1 (VOID *x)
the exception handler should be guaranteed to be installed.
I'm leaving it in until potentially after the release of
1.7.1 */
- _my_tls.init_exception_handler (_cygtls::handle_exceptions);
+ /* _my_tls.init_exception_handler (_cygtls::handle_exceptions); */
+ /* Correction: install a temporary registration with our handler
+ at the head of the list, and unlink it before returning. */
+ extern exception_list *_except_list asm (%fs:0);
+ exception_list seh;
+ seh.handler = _cygtls::handle_exceptions;
+ seh.prev = _except_list;
+ _except_list = seh;
if (p == NULL)
p = __cygwin_user_data;
@@ -390,6 +397,8 @@ dll_dllcrt0_1 (VOID *x)
res = -1;
else
res = (DWORD) d;
+
+ _except_list = seh.prev;
}
/* OBSOLETE: This function is obsolete and will go away in the
#include dlfcn.h
#include signal.h
#include stdio.h
void my_handler (int sig)
{
printf (sig %d\n, sig);
}
int main( int argc, char** argv )
{
signal (SIGSEGV, my_handler);
*(volatile unsigned int *)0;
void* dll = dlopen( mutex.dll, RTLD_NOW );
dlclose( dll );
}
#include dlfcn.h
#include signal.h
#include stdio.h
void my_handler (int sig)
{
printf (sig %d\n, sig);
}
int main( int argc, char** argv )
{
signal (SIGSEGV, my_handler);
void* dll = dlopen( mutex.dll, RTLD_NOW );
*(volatile unsigned int *)0;
dlclose( dll );
}
--
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 SIGEMT under Cygwin
This is a FYI on subject: Problem appears with httpd V2.0.63 as well as V2.2.2. I have compiled both versions and they both act the same. Sounds like a generic problem with cygwin, an educated guess. There is some code in connection.c which comments the fact that you should define NO_LINGCLOSE for specific OS's so I added CYGWIN to the list. No Change in behavior. - Paul -- 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: Statically initialising pthread attributes in dynamic dlls.
On Wed, Feb 24, 2010 at 01:39:31AM +, Dave Korn wrote: On 24/02/2010 00:44, Christopher Faylor wrote: I never saw the cygwin exception handler on the list twice when I was debugging this. That isn't supposed to happen and I don't see how it could happen unless Windows is doing it since the code in _cygtls::init_exception_handler is supposed to prevent that and, if it was on the list twice bad stuff happened. That actually looks like a typo above since you seem to have typed the same address twice. Anyway, I've revisited this code, just like I knew I would, and have added YA in a long series of tweaks which seems to fix your particular problem. The fix is in the latest snapshot. :( I think I can see where the next problem is going to arise already. If we move el to the front of the list each time, what's going to happen when we eventually return from LoadLibrary, and el.prev is still pointing at the now-deallocated stack frames where LoadLibrary created its temporary EXCEPTION_REGISTRATION structures ? Unless you can show that LoadLibrary isn't smart enough to clean up after itself in this scenario, I think it's a non-issue. 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: [ANNOUNCEMENT] Updated: Unicode text editor MinEd 2000.16
Hallo Thomas, Der Link zur Standalone-Version (http://towo.net/mined/download/mined-2000.16-windows.zip) zeigt einen 404-Fehler. Hab stattdessen das Cygwin-Paket von Hand ausgepackt. Funktioniert. Der Eintrag im Explorer-Kontextmenü ist eine gute Idee, aber vielleicht sollte der besser optional sein, z.B. mit einem separaten Paket? Ein Fehler mit dem Kontextmenü: eine Datei names New Text Document.txt wird als New geöffnet. Schönen Gruß, Andy -- 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
Cygwin 1.7.1 missing startxwin.sh
Good day, I have a a couple of queries with regards to Cygwin, I have a procedure for an old version of cygwin which we use at to access remote servers.I myself am unfortunately not familier with cygwin at all. As part of the procedure we had to add the following line to the cygwin.bat file. bash --login -i /usr/X11R6/bin/startxwin.sh - According to the procedure this was done to set x to start automatically once you login. The next part of the procedure is to change the file startxwin.sh However this was obviously done with an older version of cygwin with the new version of cygwin I cannot find the file startxwin.sh or the directory /usr/X11R6. The selections made during the installation procedure is to install the following. Under net: autossh: Automatically restart SSH sessions and tunneling. openldap: Lightweight Directory Access Protocol openldap-devel: Lightweight Directory Access Protocol openssh: The OpenSSH server and client program openssl: The OpenSSL runtime environment openssl097: The OpenSSL 0.9.7 runtime environment Under Xterm: xorg-x11-xwin: Cygwin/X X server - In the new version of cygwin I cannot find this,managed to track it down to your site x.cygwin.com xterm: Xterm - X terminal Basically I have two queries. 1. Where do I find the file startxwin.sh or is it not applicable anymore? 2. Is the Xwindows install on the alternate site the replacement for the XX server I cannot find under the xterm install options? (I assume so and have installed this as replacement) Kind Regards, Johan Van Zyl PS: IANICE -- 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: Unicode text editor MinEd 2000.16
MinEd 2000.16 (Feb 2010) This release of MinEd introduces two major new features for which it is a beta release and I would especially appreciate comments on them: * Self-made interactive selection highlighting, meaning: - Mouse selection highlighting now works in other terminals than just xterm, including the cygwin console (from cygwin 1.7.2). - Selection highlighting is also applied for keyboard selection. A few options are offered to tune selection highlighting; open the Paste buffer menu (from the Options menu or the %= flags) and choose options in the visual selection section. - Del key changed: With new selection highlighting, the function of the Del keypad key could finally be changed to meet more common user expectations (dual-mode behaviour): if a visual selection is active, delete it, otherwise delete next character. * Rectangular copy and paste. - Applying interactive rectangular selection highlighting. Both cygwin releases (the cygwin package and the Windows stand-alone package) register MinEd for invocation from the Windows Explorer context menu for text files. Summary of major enhancements in this release (if relevant for cygwin): Text editing features: * New rectangular copy/paste area mode. * Enhanced smart quotes algorithm and input support for apostrophe. * Support fow Hawai'ian input. Interactive: * Self-made visual selection highlighting, supporting all terminals. * Changed Del keypad key to more common behaviour. * Calculated dim attribute for line markers in xterm and mintty. * Menu navigation: On a submenu entry, cursor-right enters the submenu too. File handling: * The text position is now more easily remembered. Interworking: * For cygwin: * Fixed creation of inter-window paste buffer in case hard link does not work (on FAT or network drives). * Enabled mouse navigation without button pressed for cygwin (1.7.2) console. * With cygwin 1.7.2, mouse interaction will be enhanced. * For mintty/cygwin: * Various tuning measures to make optimal use of this fine terminal. * The mined scrollbar is now enabled by default. (For right-to-left text editing, reduce visual confusion with -o.) Mined is a powerful text editor with a comprehensive yet concise and easy-to-use user interface supporting modern interaction paradigms, and fast, small-footprint behaviour. Mined provides both extensive Unicode and CJK support offering many specific features and covering special cases that other editors are not aware of (like auto-detection features and automatic handling of terminal variations, or Han character information). It was the first editor that supported Unicode in a plain-text terminal (like xterm or rxvt). Basically, mined is an editor tailored to reliable and efficient editing of plain text documents and programs, with features and interactive behaviour designed for this purpose. To install mined on cygwin, run the cygwin setup program, in the Select Packages menu, open the Editors category and select the mined package. More information (with screenshots, feature overview and change log) and download are available from the mined web site at http://towo.net/mined/ Mined is co-hosted at sourceforge and has a mailing list which can be subscribed at https://lists.sourceforge.net/lists/listinfo/mined-editor Thomas Wolff mi...@towo.net
