Future of emacs maintainership
Hi cygwinners, as you mentioned in the last months, i'd a lot of problems to fulfill my task as cygwin emacs maintainer. This has many reasons. There is this rsync/cygport problem mentioned sometimes before i have at my machine, but also a lack of time for the cygwin work coming from a really stressful personal time. And it isn't foreseeable that this will change in the next time. So i've no chance but giving back the gold star in the hope that someone else will take the maintainership for emacs. May be Ken Brown is the right one. I'm really sorry, Steffen
Re: Future of emacs maintainership
On May 14 08:28, Steffen Sledz wrote: Hi cygwinners, as you mentioned in the last months, i'd a lot of problems to fulfill my task as cygwin emacs maintainer. This has many reasons. There is this rsync/cygport problem mentioned sometimes before i have at my machine, but also a lack of time for the cygwin work coming from a really stressful personal time. And it isn't foreseeable that this will change in the next time. So i've no chance but giving back the gold star in the hope that someone else will take the maintainership for emacs. May be Ken Brown is the right one. I'm really sorry, Steffen No worries. Thanks for your help. Ken? Would you mind to take over? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Future of emacs maintainership
On 5/14/2009 4:10 AM, Corinna Vinschen wrote: On May 14 08:28, Steffen Sledz wrote: Hi cygwinners, as you mentioned in the last months, i'd a lot of problems to fulfill my task as cygwin emacs maintainer. This has many reasons. There is this rsync/cygport problem mentioned sometimes before i have at my machine, but also a lack of time for the cygwin work coming from a really stressful personal time. And it isn't foreseeable that this will change in the next time. So i've no chance but giving back the gold star in the hope that someone else will take the maintainership for emacs. May be Ken Brown is the right one. I'm really sorry, Steffen No worries. Thanks for your help. Ken? Would you mind to take over? I'm willing to do it, provided you're willing to have me as a maintainer, given my minimal qualifications. As I said in (http://cygwin.com/ml/cygwin-apps/2009-04/msg00061.html), I have no programming or debugging skills. If you still want me to do it, the links to my builds of emacs-23 packages are in http://cygwin.com/ml/cygwin-apps/2009-04/msg00116.html; these are intended to replace the existing 22.1-3 test packages (cygwin 1.7 only). I *think* the packaging is OK, but, since I've never built a cygwin package before, I'd appreciate it if you or one of the experienced package maintainers would take a look before you upload it. I'm leaving town tomorrow for a few days. I will have email access, but I won't have time to deal with any problems. So I probably shouldn't send out an announcement about the new packages until I return (Tuesday or Wednesday). Ken
Re: [Preliminary Patch] setup.exe size/position restore on startup
It seems unclear (unlikely?) that this feature is definitely wanted, but on the chance that it is, responses to comments below: On Wed, May 13, 2009 at 10:23 PM, Christopher Faylor wrote: Thanks for the patch but since you asked, I don't understand why you chose to add so many new files and so many new classes. It doesn't seem like what you are doing calls for new classes. My rational for adding the PropSheetGeometry class is that there are a number of values that need to be available both to PropSheet and to WinGeometrySetting, so I packaged them together. They could all be made statics or maybe a static struct within PropSheet if that is better. With respect to the WinGeometrySetting class, all of the other saved settings are implemented as separate classes (by my reading, I think they have to be...) using libgetopt++. There is a mild non-standardization as to whether a class inheriting from UserSetting goes in it's own file or not: ConnectionSetting, KeysSetting, and SourceSetting are all in their own h/cc files, but LocalDirSetting and SiteSetting are combined in files with the classes that use them. The README says Place all methods for a single class in a single file, and Name the source file for classes and their headers after the class. I understood that to mean that new classes should have their own files, but I realize it doesn't explicitly say that, so I can put them elsewhere if that is preferred. Also you use varying white space styles. You should stick with whatever is in the surrounding code. It is a shame that setup has so many different styles. Someone (maybe I) was asleep at the switch when the varying styles made it into the code base but there is no need to fragment things further. I just took another look at the GNU coding standards and think I see better what is required now. The mix of spaces and tabs in propsheet.cc confused me a little, but after figuring out the correct tab widths, I can see that most of it is consistent (there are a few lines that look off). To be sure, am I correct that the desired indenting is 4 spaces, with the open brace of a function lined up with the first column of the function declaration, and the opening braces of of other blocks of code indented 2 spaces from the first line of the block? I'll also change the added files to match if they stick around. I also notice I put some open-braces on the same line as their corresponding if's - I'll fix that in my next attempt if there is interest in the patch. I know that Dave asked for this but I really don't see the need to add this much machinery. I think this is a lot of work to go to for something that is run infrequently and which is usually just clicked through. For other installers, people just seem to live with whatever they do rather than kvetching the geometry of the windows. I don't think that this patch interferes with anyone running things from the command line, though I admit that whether it is useful is extremely subjective - some people won't need or ever notice it while just clicking through, but some may find it useful. I decided to give it a shot since I fall into the maximized package chooser is too big on my screen, but the default size is too small camp, and a customizable size seemed to me like it might be an acceptable compromise. In terms of reducing the changes required, if the new files for the PropSheetGeometry and even the WinGeometrySetting class are eliminated, that would also remove the changes to Makefile.am, and leave only changes in propsheet.cc and new additions to propsheet.h. That doesn't really reduce the quantity of code though, just the number of files touched. Jonathon Merz
Re: [Preliminary Patch] setup.exe size/position restore on startup
Christopher Faylor wrote: And some of us just run setup from the command line and never even bother with the GUI until it has run to completion There's that too. I am hoping to make that even more convenient eventually. I'd like to get rid of all remnants of the GUI when -q (or some other option) is specified on the command line. A, wouldn't that be nice. One additional feature that might be useful is a command line switch that allows a search through the package list that puts out a list of matches. Think of it as a grep through setup.ini On the other hand, once you've installed the base system it's pretty easy to write a script that does the same thing. And now I'm wandering off topic. Start a new thread for replies please. Ralph
Re: Future of emacs maintainership
On May 14 07:43, Ken Brown wrote: On 5/14/2009 4:10 AM, Corinna Vinschen wrote: On May 14 08:28, Steffen Sledz wrote: Hi cygwinners, as you mentioned in the last months, i'd a lot of problems to fulfill my task as cygwin emacs maintainer. This has many reasons. There is this rsync/cygport problem mentioned sometimes before i have at my machine, but also a lack of time for the cygwin work coming from a really stressful personal time. And it isn't foreseeable that this will change in the next time. So i've no chance but giving back the gold star in the hope that someone else will take the maintainership for emacs. May be Ken Brown is the right one. I'm really sorry, Steffen No worries. Thanks for your help. Ken? Would you mind to take over? I'm willing to do it, provided you're willing to have me as a maintainer, given my minimal qualifications. As I said in Everything's better than no maintaner at all, right? :) (http://cygwin.com/ml/cygwin-apps/2009-04/msg00061.html), I have no programming or debugging skills. If you still want me to do it, the links to my builds of emacs-23 packages are in http://cygwin.com/ml/cygwin-apps/2009-04/msg00116.html; these are intended to replace the existing 22.1-3 test packages (cygwin 1.7 only). I *think* the packaging is OK, but, since I've never built a cygwin package before, I'd appreciate it if you or one of the experienced package maintainers would take a look before you upload it. Just post the links to the packages in a RFU. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Package list search (was Re: [Preliminary Patch] setup.exe size/position restore on startup)
Ralph Hempel wrote on Thursday, May 14, 2009 7:06 AM: Christopher Faylor wrote: And some of us just run setup from the command line and never even bother with the GUI until it has run to completion There's that too. I am hoping to make that even more convenient eventually. I'd like to get rid of all remnants of the GUI when -q (or some other option) is specified on the command line. A, wouldn't that be nice. One additional feature that might be useful is a command line switch that allows a search through the package list that puts out a list of matches. Think of it as a grep through setup.ini You mean like 'cygcheck -p desired filename'? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com
[RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
New test release. cd release-2 wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1-src.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/emacs-X11-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/emacs-el-23.0.92-1.tar.bz2 Please delete the 22.1-3 (test) packages, leaving 21.2-13 as current and 21.2-12 as previous. Ken
Re: Package list search (was Re: [Preliminary Patch] setup.exe size/position restore on startup)
Thrall, Bryan wrote: One additional feature that might be useful is a command line switch that allows a search through the package list that puts out a list of matches. Think of it as a grep through setup.ini You mean like 'cygcheck -p desired filename'? No, not quite. If I do something like: cygcheck -p find I get a long list of matches that includes xorg man pages and zsh. What I expected was a list of packages that have find in the first line of the package description (the @ line) or maybe in the requires: line. Ralph
Re: Future of emacs maintainership
On Thu, May 14, 2009 at 07:43:40AM -0400, Ken Brown wrote: On 5/14/2009 4:10 AM, Corinna Vinschen wrote: On May 14 08:28, Steffen Sledz wrote: Hi cygwinners, as you mentioned in the last months, i'd a lot of problems to fulfill my task as cygwin emacs maintainer. This has many reasons. There is this rsync/cygport problem mentioned sometimes before i have at my machine, but also a lack of time for the cygwin work coming from a really stressful personal time. And it isn't foreseeable that this will change in the next time. So i've no chance but giving back the gold star in the hope that someone else will take the maintainership for emacs. May be Ken Brown is the right one. I'm really sorry, Steffen No worries. Thanks for your help. Ken? Would you mind to take over? I'm willing to do it, provided you're willing to have me as a maintainer, Thanks for volunteering. As long as you're as responsive as possible to problem email (which you seem to be), I think this will be great. cgf
Stupid setup.exe tricks
On Thu, May 14, 2009 at 08:06:14AM -0400, Ralph Hempel wrote: Christopher Faylor wrote: And some of us just run setup from the command line and never even bother with the GUI until it has run to completion There's that too. I am hoping to make that even more convenient eventually. I'd like to get rid of all remnants of the GUI when -q (or some other option) is specified on the command line. A, wouldn't that be nice. One additional feature that might be useful is a command line switch that allows a search through the package list that puts out a list of matches. Think of it as a grep through setup.ini On the other hand, once you've installed the base system it's pretty easy to write a script that does the same thing. And now I'm wandering off topic. Start a new thread for replies please. My hidden agenda is to make setup.exe completely usable as a command-line package installer. Sometimes I think that the only way to do that is to write a wrapper around setup.exe to do more interesting stuff and filter its output. Sometimes I think it really should be done in the setup.exe code itself. But then I take a close look at the setup.exe code itself and... cgf
[ITA] cygwin-x-doc
I guess I am the de-facto maintainer of this package, as I have been updating the same content which is published on the x.cygwin.com website. Given that I've gone to the trouble of updating the content, I suppose I should produce an updated package, just in case anyone actually installs it and reads these files locally. At the moment, it seems I can't build this package natively under cygwin as it uses jadetex and docbook-dsssl-stylesheets, which aren't officially packaged, and I wasn't able to find (working) unofficial packages for. http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/cygwin-x-doc-1.1.0-1-src.tar.bz2 http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/cygwin-x-doc-1.1.0-1.tar.bz2 http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/setup.hint The setup.hint is unchanged.
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On 5/14/2009 10:22 AM, Ken Brown wrote: New test release. Well, I'm off to a great start. I just realized that I forgot to edit the README to reflect the fact that I'm the new maintainer. When I built the packages a month ago, I thought I was just helping out. Is there still time for me to fix this without bumping the release number? Ken
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On May 14 16:52, Ken Brown wrote: On 5/14/2009 10:22 AM, Ken Brown wrote: New test release. Well, I'm off to a great start. I just realized that I forgot to edit the README to reflect the fact that I'm the new maintainer. When I built the packages a month ago, I thought I was just helping out. Is there still time for me to fix this without bumping the release number? It hasn't been uploaded yet, so, yes, sure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [Preliminary Patch] setup.exe size/position restore on startup
On Thu, May 14, 2009 at 11:02 AM, Christopher Faylor wrote: I know that Dave asked for this but I really don't see the need to add this much machinery. ?I think this is a lot of work to go to for something that is run infrequently and which is usually just clicked through. ?For other installers, people just seem to live with whatever they do rather than kvetching the geometry of the windows. I don't think that this patch interferes with anyone running things from the command line, The issue is adding code complexity. setup.exe is already a nightmare so adding another two classes and control flow for what I would consider to be a little-used feature doesn't make sense to me. Understood. I'll let it go. Jonathon Merz
Re: [ITA] cygwin-x-doc
On May 14 18:03, Jon TURNEY wrote: http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/cygwin-x-doc-1.1.0-1-src.tar.bz2 http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/cygwin-x-doc-1.1.0-1.tar.bz2 http://www.dronecode.org.uk/cygwin/release/cygwin-x-doc/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
Ken Brown wrote: New test release. cd release-2 wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1-src.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/emacs-X11-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/emacs-el-23.0.92-1.tar.bz2 Please delete the 22.1-3 (test) packages, leaving 21.2-13 as current and 21.2-12 as previous. Ken In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93).
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On 5/14/2009 4:55 PM, Corinna Vinschen wrote: On May 14 16:52, Ken Brown wrote: Well, I'm off to a great start. I just realized that I forgot to edit the README to reflect the fact that I'm the new maintainer. When I built the packages a month ago, I thought I was just helping out. Is there still time for me to fix this without bumping the release number? It hasn't been uploaded yet, so, yes, sure. OK, it's fixed now. Thanks. Ken
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On 5/14/2009 5:57 PM, Mark Harig wrote: In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93). Yes, I knew about 23.0.93. I built it for myself and have been using it, just to make sure there were no regressions. If 23.0.92 proves stable enough to be promoted to current, then I'll think about doing something like what you suggested. But let's wait and see what happens when it gets released and people start using it. The transition from 21.2 to 23.0 might take some time for people to adapt to. Emacs 21.2 was released 7 years ago, and there's been quite a bit of development since then. Ken
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
Ken Brown wrote: On 5/14/2009 5:57 PM, Mark Harig wrote: In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93). Yes, I knew about 23.0.93. I built it for myself and have been using it, just to make sure there were no regressions. If 23.0.92 proves stable enough to be promoted to current, then I'll think about doing something like what you suggested. But let's wait and see what happens when it gets released and people start using it. The transition from 21.2 to 23.0 might take some time for people to adapt to. Emacs 21.2 was released 7 years ago, and there's been quite a bit of development since then. Ken People who are willing to use the not-yet-released Cygwin 1.7 and the not-yet-released Emacs 23 ought to be expecting some instability. Alternatively, if Emacs 22.3 does not have compilation problems with Cygwin 1.7, then it could be provided as the Curr version, and one or more versions of Emacs 23 could be provided as Exp. In addition, providing more versions might help in your supporting Emacs -- if someone has a problem with one version of Emacs, then one troubleshooting strategy would be to have the user reproduce the problem on a later or earlier version. If the problem disappears, then you have narrowed down the source of the problem.
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
On Thu, May 14, 2009 at 07:41:30PM -0400, Mark Harig wrote: Ken Brown wrote: On 5/14/2009 5:57 PM, Mark Harig wrote: In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93). Yes, I knew about 23.0.93. I built it for myself and have been using it, just to make sure there were no regressions. If 23.0.92 proves stable enough to be promoted to current, then I'll think about doing something like what you suggested. But let's wait and see what happens when it gets released and people start using it. The transition from 21.2 to 23.0 might take some time for people to adapt to. Emacs 21.2 was released 7 years ago, and there's been quite a bit of development since then. People who are willing to use the not-yet-released Cygwin 1.7 and the not-yet-released Emacs 23 ought to be expecting some instability. Please don't argue with a package maintainer about what they should be releasing especially when you are talking about more work for them. Alternatively, if Emacs 22.3 does not have compilation problems with Cygwin 1.7, then it could be provided as the Curr version, and one or more versions of Emacs 23 could be provided as Exp. Alternatively, if this is really important to you then you could build the package yourself. cgf
Re: [Preliminary Patch] setup.exe size/position restore on startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jonathon Merz on 5/14/2009 2:56 PM: On Thu, May 14, 2009 at 11:02 AM, Christopher Faylor wrote: I know that Dave asked for this but I really don't see the need to add this much machinery. ?I think this is a lot of work to go to for something that is run infrequently and which is usually just clicked through. ?For other installers, people just seem to live with whatever they do rather than kvetching the geometry of the windows. The issue is adding code complexity. setup.exe is already a nightmare so adding another two classes and control flow for what I would consider to be a little-used feature doesn't make sense to me. Understood. I'll let it go. The idea of preserving geometry is nice to me; I think you are finding more resistance due to your coding style choices, not due to the concept itself. It may still be worth your time to continue thinking about a cleaner way to perform this task; I would certainly like it if the window remembered its former size. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoM7TQACgkQ84KuGfSFAYCBMQCgh2+HGuM5xDiKPTYcxRtBqa2n k4MAmQEb4x4b1kJFLrZZ+r7UWexGpV+o =JXOP -END PGP SIGNATURE-
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/14/2009 7:50 PM: People who are willing to use the not-yet-released Cygwin 1.7 and the not-yet-released Emacs 23 ought to be expecting some instability. Please don't argue with a package maintainer about what they should be releasing especially when you are talking about more work for them. At any rate, I'm rather tired of several YEARS of choosing the 'Exp'erimental version of emacs from setup.exe, all because 22.1-3 works better for me than the 'Stable' version. I'm all for whatever you provide, and will be grateful for whatever you decide to mark as stable. Thanks again for volunteering to do a build, and rest assured that it will be used. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoM7rkACgkQ84KuGfSFAYBB6QCgqNXJ7NId2RtAo+B20i9y46ln 7AkAoIbLdbFGdhz6LfXIXHFSuhLtsEWR =/eFG -END PGP SIGNATURE-
Re: Xwin X Server crashing when using -query startup option to Fedora 11
Jon TURNEY wrote: Mark Chesterfield wrote: Hi, I am trying to connect to the preview release of Fedora 11 running Gnome 2.26 on my laptop and am getting an Xwin server crash. This isn't a crash. The Xwin server is terminating with a error. I know my Xwin Server works with the -query startup option as I use this option at work with the laptop. So i have a couple of questions: a. Have I hit a bug? b. Does it appear to be an Xwin bug or should I instead be submitting it to the Fedora 11 support forums and bug handling menchanisms? c. Any ideas for a workaround ? Fatal server error: XDMCP fatal error: Session declined Maximum number of open sessions from your host reached This error says that XWin couldn't start an XDMCP session as the remote host declined for the reason stated. Since your XWin can start XDMCP sessions with other remote hosts, I think this is a bug or configuration error in your Fedora 11 host. Thanks for your response. I had also reached the conclusion that it was a Fedora 11 issue. Cheers -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server fails to start on Vista
It worked with /usr/bin/XWin :1 The X icon appeared and the xterm application worked as expected. netstat -p showed nothing before or after XWin started. It also showed nothing with a live SSH connection started from my Cygwin bash shell. After starting XWin with XWin :1 the process appeared as expected in the Windows task manager. Jon TURNEY wrote: You're not running a different X server as well, are you? Check the output of netstat -p for lines of the form TCP yourcomputername:6000 ? Does /usr/bin/XWin :1 -multiwindow -clipboard -silent-dup-error fail in the same way? -- View this message in context: http://www.nabble.com/X-server-fails-to-start-on-Vista-tp2345p23546159.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
standard X Clients gone?
Where did the standard X clients, such as xterm, xhost, xdpyinfo, xclock, and xeyes go? I've tried to install several times. There is no 'xinit' package from the 'X11' category. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server fails to start on Vista
Kim Goldov wrote: It worked with /usr/bin/XWin :1 The X icon appeared and the xterm application worked as expected. This seems pretty strong evidence that the error message you reported is correct. _XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running The server can't start, either because it's not being allowed to bind to port 6000, or because something else already has. netstat -p showed nothing before or after XWin started. It also showed nothing with a live SSH connection started from my Cygwin bash shell. Sorry, I meant to type netstat -b not netstat -p After starting XWin with XWin :1 the process appeared as expected in the Windows task manager. Jon TURNEY wrote: You're not running a different X server as well, are you? Check the output of netstat -p for lines of the form TCP yourcomputername:6000 ? Does /usr/bin/XWin :1 -multiwindow -clipboard -silent-dup-error fail in the same way? -- 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/
standard X Clients gone?
Nevermind... the mirror I used the first time around just didn't have the complete set. Where did the standard X clients, such as xterm, xhost, xdpyinfo, xclock, and xeyes go? I've tried to install several times. There is no 'xinit' package from the 'X11' category. -- 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/doc ChangeLog new-features.sgml pat ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-05-14 10:03:26 Modified files: winsup/doc : ChangeLog new-features.sgml pathnames.sgml Log message: * new-features.sgml: Add automounting of /, /usr/bin, and /usr/lib. * pathnames.sgml (pathnames-intro): Be more verbose about POSIX and Win32 paths. (mount-table): Add auto flag. Add a paragraph about /usr/bin and /usr/lib. (pathnames-mount-ex): Enhance flags output. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.204r2=1.205 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.8r2=1.9 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/pathnames.sgml.diff?cvsroot=srcr1=1.40r2=1.41
src/winsup/doc ChangeLog faq-setup.xml faq-usi ...
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-05-14 11:03:43
Modified files:
winsup/doc : ChangeLog faq-setup.xml faq-using.xml
pathnames.sgml
Log message:
* faq-setup.xml (faq.setup.upgrade-mountpoints): New entry.
* faq-using.xml (faq.using.directory-structure): Align example to
latest mount output.
* pathnames.sgml (mount-table): Add note about upgrade helper scripts
to create /etc/fstab and /etc/fstab.f/${USER}.
Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.205r2=1.206
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-setup.xml.diff?cvsroot=srcr1=1.13r2=1.14
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-using.xml.diff?cvsroot=srcr1=1.20r2=1.21
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/pathnames.sgml.diff?cvsroot=srcr1=1.41r2=1.42
winsup/cygwin ChangeLog mount.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-05-14 14:44:31 Modified files: cygwin : ChangeLog mount.cc Log message: * mount.cc (mount_info::init): Remove MOUNT_CYGWIN_EXEC setting when auto-mounting /usr/bin. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4487r2=1.4488 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/mount.cc.diff?cvsroot=uberbaumr1=1.37r2=1.38
What is Cygwin DLL emulation Layer ?
Hi All, I am newbie to Cygwin world. I have very basic doubt regarding cygwin. My question is 1.) Why you have designed cygwin as DLL ? What's the advantage ? 2.) What is Cygwin emulation layer ? 3.) How Cygwin work internally. Please explain in brief ? I have searched for the answers in Google,and cygwin mailing list, but still I am not getting the right answer for this question.Or I am not satisfied with the answers I got. Could you please help me out to resolve my doubts ? Thanks Regards, Neeraj Sahu -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: What is Cygwin DLL emulation Layer ?
Neeraj Sahu wrote: Why you have designed cygwin as DLL ? What's the advantage ? The advantage relative to what? Propose another way it could work, and we can compare and contrast the alternatives. What is Cygwin emulation layer ? cygwin1.dll. It sits between POSIX type programs and the Windows API, allowing these programs to believe they are running on a POSIX type operating system, so they don't have to know how to use the Windows equivalent APIs. In addition to the Cygwin DLL, there is also a huge library of POSIX software ported to use the DLL, to provide a complete POSIX operating environment. These things are not Cygwin proper, but they are considered part of a working Cygwin system, in the same way that the Linux kernel is only part of a complete Linux operating system. How Cygwin work internally. Please explain in brief ? The Cygwin DLL translates POSIX system calls into Windows system calls. Where there is no exact match between the behavior of Windows and the expected behavior on a POSIX operating system, the Cygwin DLL provides the functionality to make up the gap. In some places the thickness of the DLL is very thin, while in other places it has to do a lot of work to provide POSIX behavior in terms of the Windows API. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 13 23:49, Matthias Andree wrote: Am 13.05.2009, 17:17 Uhr, schrieb Corinna Vinschen corinna-cyg...@cygwin.com: I followed the suggestion to use UTF-8 for internal conversions when the locale is set to C. This will also be used as default conversion when converting the Windows environment from UTF-16 to multibyte, unless the environment contains a valid LC_ALL/LC_CTYPE/LANG setting. The current working directory was also potentially unusable, if an application switched the locale. Now the CWD is re-evaluated after a setlocale call. Is Unicode normalization an issue here? Not really, I guess. Either a character is available or it isn't. We don't have composition or decomposition capabilities for most multibyte character sets anyway. If at all, we could only do that for SJIS, EUCJP, and GBK. None of them would profit a lot of that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs 23
Ken Brown-6 wrote: On 5/13/2009 2:25 PM, Marc Girod wrote: The lines in the postinstall scripts involving desktop-database and mime-database were added by cygport, not by me. Indeed, no visible problem. One thing I noticed, is that I used cperl-mode 6.2, and 23.0.92 brought back 5.3 (21.2 had 4.23...). Do you think it would be worth upgrading it for everybody? Or would this be a departure from 23 as on other platforms, and therefore unwanted? I just byte-compile 6.2 on 23.0.92, and got a lot of warnings for various obsolete practices... I'll send the transcript to Ilya... Thanks, Marc -- View this message in context: http://www.nabble.com/insert-directory-function-in-Gnu-emacs-returns-nil-tp23523466p23536460.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
Ken Brown-6 wrote: I've built emacs 23 under both cygwin 1.5 and 1.7, and it runs fine for me except for a glitch involving time zones: Emacs gets the local time zone wrong by 4 hours. I am using your port on 1.7, and cannot reproduce. In my *scratch* buffer: Time-stamp: 2009-05-14 10:33:36 emagiro (getenv TZ) nil I filled the template: Time-stamp: with the time-stamp command, and the time matches my clock. Note that my local timezone is now: src date Thu May 14 10:35:36 GMTDT 2009 Looking at the sources, the most suspicious place given your description, seems to be msdos.c, around lines 4453-4494... Thanks, Marc -- View this message in context: http://www.nabble.com/Debugging-a-time-zone-problem-tp21876155p23537290.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
I/O errors seen on programs passing via cygwin under heavy stress
I am routinely having problems with programs compiled and running via cygwin if they are using network shares and the level of I/O stress is high. In a typical case, I have a single Windows Server 2003 node with a single share open to all, and 3 Windows Server 2003 clients each running an up-to-date cygwin who have mounted the share via a mount //ip address/share /test. On each client I compile and set off the ping_pong locking test which does byte level locking - so far so good. If on one of those clients I then set off a heavy load generator compiled and running within the cygwin environment e.g. iozone, the ping_pong tests start reporting 'permission denied' and 'write failed'. iozone itself will generally fail with a write error as well. I have similar issues when using a range of other tests, including when using Samba on Linux as the back end server. I have tested with different systems and different networks and seen the same result. However, if the load generator is a Windows native application, the problem is not seen. It looks to me as if the cygwin environment has problems if the I/O traffic becomes excessive. Note, if the application tries a retry of a failed write after a short delay, it will generally succeed, reinforcing my suspicions. Googling and looking at the mail archives didn't seem to throw up anything similar, however. Is this a known issue ? Are there ways of tuning the cygwin I/O subsystem ? Thanks, Gavin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug to setup Cygwin on Windows Server 2008 64bits
I still block on the prompt bash. I don't arrive to have a valid and read shell. When i run ssh-host-config, i have error with bash.exe and Windows 2008 send me a repport. I have try with the -l but not success. With the .bat it's the same Thanks for your help Andy Koppe wrote: 2009/5/7 Georg Nikodym: On 7-May-09, at 10:56 AM, Kyeto wrote: I have disabled DEP and now Cygwin run. But i have just the pompt with : bash-3.2$ : _ None commands are available When i do a ls = command not found. It's the same for a lot (touch, chmod ...) But, pwd, cd work Normally, people start cygwin using cygwin.bat (or an icon on their desktop that does the same). This sets up some useful stuff. From the picture in your previous post, you just started a shell (bash.exe) inside a command window. In other words, there no guarantee that any useful environment was set up. Yep. To get the usual environment, bash needs to be invoked with option --login (or -l), which makes it a login shell and ensures that /etc/profile is executed. Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/Bug-to-setup-Cygwin-on-Windows-Server-2008-64bits-tp23422628p23537721.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
Marc Girod wrote: Looking at the sources, the most suspicious place given your description, seems to be msdos.c, around lines 4453-4494... and even more so with lines 4450-4452: /* Time zone determined from country code. To make this possible, the country code may not span more than one time zone. In other words, in the USA, you lose. */ There are 4 zones in the US? Countries with several timezones are the large ones: Russia, China, India, Canada, Brazil,... Unfortunately, there are also populated (with users, I mean)... For them, a different mechanism seems to be needed. Er... why does gdb affect? Marc -- View this message in context: http://www.nabble.com/Debugging-a-time-zone-problem-tp21876155p23538459.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs 23
On 5/14/2009 4:34 AM, Marc Girod wrote: One thing I noticed, is that I used cperl-mode 6.2, and 23.0.92 brought back 5.3 (21.2 had 4.23...). Do you think it would be worth upgrading it for everybody? Or would this be a departure from 23 as on other platforms, and therefore unwanted? I just built the plain vanilla source, which is intended for all platforms. I don't think the cygwin port should be different unless there's a good reason. I just byte-compile 6.2 on 23.0.92, and got a lot of warnings for various obsolete practices... That could explain why emacs-23 isn't shipping that version. I'll send the transcript to Ilya... Keep me posted. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
On 5/14/2009 5:38 AM, Marc Girod wrote: Ken Brown-6 wrote: I've built emacs 23 under both cygwin 1.5 and 1.7, and it runs fine for me except for a glitch involving time zones: Emacs gets the local time zone wrong by 4 hours. I am using your port on 1.7, and cannot reproduce. BTW, my original report (that the time zone was off by 4 hours) was misleading. After comparing my results with those of Angelo Graziosi in Italy, I realized that, for both Angelo and me, emacs thought our local time zone was GMT minus one hour. (This was in February, before daylight savings time.) Looking at the sources, the most suspicious place given your description, seems to be msdos.c, around lines 4453-4494... Thanks for looking into this. I'm about to leave town for a few days, but maybe I'll make another attempt when I return (unless you've already solved it before then). Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: What is Cygwin DLL emulation Layer ?
Neeraj Sahu wrote on Thursday, May 14, 2009 2:51 AM: I have searched for the answers in Google, and cygwin mailing list, In addition to Google, the ML archives, and Warren Young's comments, you should might want to look at the FAQ and other documentation. Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
2009/5/14 Corinna Vinschen corinna-cyg...@cygwin.com: Should the following part not be modified? winsup/cygwin/fhandler_console.cc: dev_state-con_mbtowc = __mbtowc; dev_state-con_wctomb = __wctomb; I'd rather not. It only affects the console and if LANG=C I'd rather see the single bytes which make up the path instead of the corresponding UTF-8 character. Hm, maybe I misunderstood. In which manner should this be modifed? I think: dev_state-con_mbtowc = __mbtowc == __ascii_mbtowc ? __utf8_mbtowc : __mbtowc; dev_state-con_wctomb = __wctomb == __ascii_wctomb ? __utf8_wctomb : __wctomb; -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using rand_r
On 2009-05-14 05:49Z, Nicholas Sherlock wrote: David Billinghurst wrote: Nicholas Sherlock wrote: Hey everyone, I'm trying to use the function rand_r with gcc-4 in Cygwin 1.7, all my packages are up to date. It's supposed to be defined in stdlib.h, and I can see it there. But if I compile a program which uses it, I get: warning: implicit declaration of function 'rand_r'. The reason seems to be the check for #ifndef __STRICT_ANSI__ in stdlib.h. Even though I'm compiling with -std=c99, __STRICT_ANSI__ still gets declared, so the definition of rand_r is unavailable. This seems to be the same problem stated here: '-std=c99' correctly gives a diagnostic because rand_r() is not in C99. Try -std=gnu99. It doesn't define __STRICT_ANSI__ This doesn't answer your question, unfortunately. Thanks, that does solve my immediate problem. But I'm really hoping to compile as vanilla C99 as I can manage, since I'll also be using my code with non-GNU compilers. If you want consistently identical results with different compilers, then you'll need to write your own routine anyway (which you can do in strictly-conforming C). See the rationale for myrand() here: http://www.opengroup.org/onlinepubs/95399/functions/rand.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Selling management on Cygwin
If someone could help, perhaps by briefly explaining what it is they're worried about, and why they needn't be, I would greatly appreciate it. I have no idea what your management will be worried about, but I suggest that you explain to them how much more productive it makes you at your job, and that the dollar cost to them is zero. That's how I sold it to my management. No one here asked me whether it was safe to install open source software, but if they had I was ready to explain that it's a well established and stable product, I've been using it and contributing to it for many years, and have never had a problem with it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 14 21:39, IWAMURO Motonori wrote: 2009/5/14 Corinna Vinschen corinna-cyg...@cygwin.com: Should the following part not be modified? winsup/cygwin/fhandler_console.cc: dev_state-con_mbtowc = __mbtowc; dev_state-con_wctomb = __wctomb; I'd rather not. It only affects the console and if LANG=C I'd rather see the single bytes which make up the path instead of the corresponding UTF-8 character. Hm, maybe I misunderstood. In which manner should this be modifed? I think: dev_state-con_mbtowc = __mbtowc == __ascii_mbtowc ? __utf8_mbtowc : __mbtowc; dev_state-con_wctomb = __wctomb == __ascii_wctomb ? __utf8_wctomb : __wctomb; Oh, ok. So I understood right. But that's exactly what I didn't want to do. The idea is that, even though UTF-8 is used for the filename conversion, the console should default to standard ASCII behaviour, unless you specify another charset before starting the first Cygwin process in the console. I'm also wondering if we should perhaps only allow either ASCII or UTF-8 as console charsets, but for now I don't want to touch this more than necessary. I just found that the console I/O doesn't work well for non-ASCII chars anyway. The core function which echos input to the terminal only handles singlebyte chars, which can be easily reproduced using copy/paste. Oh well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] Problem with national characters in directory names when using UTF-8 charset
There is something strange going on with national characters in
directory names when using Cygwin 1.7 with UTF-8. Here's a sample
session:
# test.rb
# -*- coding: utf-8 -*-
filename = File.expand_path(test.txt)
puts filename
puts File.open(filename) { |f| f.read }
# test.txt
This is a test
C:\cygwin\home\aborzenkov set LANG=en_US.UTF-8
C:\cygwin\home\aborzenkov mkdir проверка
C:\cygwin\home\aborzenkov copy test.rb проверка
C:\cygwin\home\aborzenkov copy test.txt проверка
C:\cygwin\home\aborzenkov C:\cygwin\bin\ruby проверка/test.rb
/usr/bin/ruby: No such file or directory -- проверка/test.rb (LoadError)
C:\cygwin\home\aborzenkov C:\cygwin\bin\cat проверка/test.txt
This is a test
C:\cygwin\home\aborzenkov cd проверка
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ruby test.rb
/home/aborzenkov/▒??▒N?▒??▒??▒?ч▒N?▒??▒?°/test.txt
This is a test
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\cat test.txt
/usr/bin/cat: test.txt: No such file or directory
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ls -al
/usr/bin/ls: cannot open directory .: No such file or directory
Why is it that some commands can't accept russian character in
filenames, yet work within russian directories, and other can open
filenames with russian paths, but can't work within russian
directories? It seems extremely weird to me. :-/ Also, I'm wondering
about this discrepancy:
C:\cygwin\home\aborzenkov C:\cygwin\bin\ruby /bin/irb
irb(main):001:0 Dir.chdir(проверка)
= 0
irb(main):002:0 File.expand_path(*)
=
/home/aborzenkov/\320\277\321\200\320\276\320\262\320\265\321\200\320\272\320\260/*
C:\cygwin\home\aborzenkov\проверка C:\cygwin\bin\ruby /bin/irb
irb(main):001:0 File.expand_path(*)
=
/home/aborzenkov/\016\320\277\016\321\200\016\320\276\016\320\262\016\320\265\016\321\200\016\320\272\016\320\260/*
Notice how for the same current directory (one where cygwin session
has done chdir to russian directory on its own, another where cygwin
session was started in russian directory) give different results for
File.expand_path in ruby. If I understood cygwin documentation
correctly, \016 is supposed to appear only for character that cannot
be represented with current charset (which is utf-8), yet in second
case they appear all over the place. The same thing is happening with,
for example, bash, which shows garbled pwd output when started from
within russian directory, yet works well when I chdir to that
directory manually.
What's going on?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Selling management on Cygwin
No one here asked me whether it was safe to install open source software, but if they had I was ready to explain that it's a well established and stable product, I've been using it and contributing to it for many years, and have never had a problem with it. You might add that the applications distributed with Cygwin are used to help run millions of *nix servers around the world. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
2009/5/14 Corinna Vinschen corinna-cyg...@cygwin.com: I see a couple of potential problems. What problems are those? And have some time to discuss whether these are something the user can or even should fix or workaround alone. I think that the application that use locale by the environment variable and the application that use no locale should be able to read and write the same byte sequence. However, I don't strongly request it because the applications work correctly in UTF-8. -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 14 23:06, IWAMURO Motonori wrote: 2009/5/14 Corinna Vinschen corinna-cyg...@cygwin.com: I see a couple of potential problems. What problems are those? I have no example off-hand. When I thought about it I always got sick thinking about scenarios where the library is using, say, UTF-8, and the application is using SJIS, and what happens to the filenames in this case. In theory the lib should provide what the application thinks it right. And have some time to discuss whether these are something the user can or even should fix or workaround alone. I think that the application that use locale by the environment variable and the application that use no locale should be able to read and write the same byte sequence. Ok, you got as point there. Assuming we leave out any application which deliberately uses a non-C locale which differs from the setting in the environment. Then we're getting into trouble. If Cygwin uses internally always the environment setting, we have a valid, identical byte stream for all applications using setlocale(LC_ALL, ), *and* for non locale-aware applications. But if the application uses a deliberately different setting via setlocale, ..., hmm. It should get what it asks for. Maybe, you're right. I have to test this a bit. Thanks for your input, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Problem with national characters in directory names when using UTF-8 charset
On May 14 17:35, Alexey Borzenkov wrote: There is something strange going on with national characters in directory names when using Cygwin 1.7 with UTF-8. Here's a sample session: That's what we discuss in the thread starting at http://cygwin.com/ml/cygwin/2009-05/msg00344.html I have all hands ful with japanese and chinese characters right now, I'm not going to add cyrillic chars to the picture for now :} I hope to be able to upload a better working Cygwin DLL tomorrow. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Selling management on Cygwin
-Original Message- From: Chap Harrison Sent: Tuesday, May 12, 2009 16:28 Subject: Selling management on Cygwin Hi, First time post. Believe I have read and carried out all specified do this before posting guidelines. Ok. I work for a 5-person company whose IT infrastructure is exclusively Windows Server-based, and whose mindset is very narrowly Microsoftian. I prefer *nix. Four months ago I quietly created a Windows Server 2003 machine running in a VM on a test box, installed Cygwin, and have been successfully writing running tools (mostly Perl) all this time. Now I want to persuade management to let me install Cygwin directly on the main Server 2003 box. This is not only for better interactive performance (I work remotely and need to go through one extra screen- scraper layer to get to my current Cygwin command line), but also to access some directories on the main box that aren't being shared and, consequently, can't be accessed from my current Cygwin. I expect to be met with plenty of FUD. I honestly don't know what kind of concerns arguments will be raised, but I feel certain they will be garden variety. However, since I'm not a management or IT type, nor a Windows expert, nor a Cygwin expert, I am unprepared to argue the case. Please note, none of these issues are meant to imply that other solutions do not have these issues, these are just some of the issues we have received from customers' management about tools, including Cygwin. OOS: * Licensing * IP liability assurance / indemnification * Entity backed product lifecycle and migration. Support: * Who supports it, contracted terms. * Warranty * Other vendors will not support the system if you install it. CM: * Feature Stability * Interoperability testing (and costs associated of doing something new) Security: * Who guarantees safety * Foreign national/government written code * disclosure of vulnerabilities If someone could help, perhaps by briefly explaining what it is they're worried about, and why they needn't be, I would greatly appreciate it. Alternately, a link to an article would be nice (I haven't found any so far). In some ways this is more of an issue about open source software in general, but I'm sure there will be questions specifically about Cygwin and the extent to which it touches Windows OS innards. Any guidance would be helpful! Maybe some one else can fill in the outline. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 14 16:42, Corinna Vinschen wrote: On May 14 23:06, IWAMURO Motonori wrote: 2009/5/14 Corinna Vinschen corinna-cyg...@cygwin.com: I see a couple of potential problems. What problems are those? I have no example off-hand. When I thought about it I always got sick thinking about scenarios where the library is using, say, UTF-8, and the application is using SJIS, and what happens to the filenames in this case. In theory the lib should provide what the application thinks it right. Here's one problem. What if an application uses setenv(LANG, ...)? Do you want Cygwin to intercept all calls to setenv() to check for setting $LC_ALL/LC_CTYPE/LANG? Right now, the only time these variables are read by Cygwin is at the start of the first Cygwin process in a Cygwin process tree. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Selling management on Cygwin
If you are looking for technical reason to make cygwin the default, then give it up. Of a person has spent years on a MS system, they will be reluctant to change. Contrary to a person using a *Unix system will be very glad to use tools that they know. You'll trying to force everyone to use one OS. When I install cygwin on a new OS, I frequently swear cuss because the MS tool set is extremely difficult compared to a *Unix system I have over 25 years experienced with *Unix. I can't see any reason for making cygwin availablr to those that prefer to use it. With many years of using both, cygwin definitely take the cake. Those that choose cygwin, will quickly be more productive and learn how to cuss out MS! Long live U N I X ! Andrew Schulman wrote: No one here asked me whether it was safe to install open source software, but if they had I was ready to explain that it's a well established and stable product, I've been using it and contributing to it for many years, and have never had a problem with it. You might add that the applications distributed with Cygwin are used to help run millions of *nix servers around the world. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
git checkout problem
I've been using git for a few weeks now and recently ran into a problem that I just can't workaround. I tried updating to the cygwin 1.7 release hoping that this would fix the issue but it didn't. I found that a checkout of a branch new_file_system from the master branch (or vice versa) would result an error that a file can't be unlinked. Below is the sequence of git commands that I run that cause the problem. This is the exact sequence of commands that I run: bash-3.2$ git status # On branch master nothing to commit (working directory clean) bash-3.2$ git checkout new_file_system error: unable to unlink old 'src/libCpp/device/cdu/readManuData.cpp' (Device or resource busy) M src/libCpp/device/cdu/readManuData.cpp Switched to branch 'new_file_system' bash-3.2$ git status # On branch new_file_system # Changed but not updated: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/libCpp/device/cdu/readManuData.cpp # no changes added to commit (use git add and/or git commit -a) bash-3.2$ git reset --hard HEAD is now at 5d9a836 Merge from CC branch to master bash-3.2$ strace -o /c/temp/cygwin17.bug --mask=all git checkout master error: unable to unlink old 'src/libCpp/services/flash.cpp' (Device or resource busy) M src/libCpp/services/flash.cpp Switched to branch 'master' bash-3.2$ git status # On branch master # Changed but not updated: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: src/libCpp/services/flash.cpp # no changes added to commit (use git add and/or git commit -a) Here is a portion of the strace log where the file (flash.cpp) is referenced (the full log is over 1MB which is why I didn't include it): 34 5526393 [main] git 4640 fhandler_base::open: (\??\C:\repo\cvs\abc-git\src\libCpp\services\cdu\flashvm46.cpp, 0x100A01) 58 5526451 [main] git 4640 alloc_sd: uid 11962, gid 11477, attribute 1ED 34 5526485 [main] git 4640 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-30099031-893089305-1333819168-1962 (+) 34 5526519 [main] git 4640 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-30099031-893089305-1333819168-1477 (+) 37 5526556 [main] git 4640 alloc_sd: ACL-Size: 100 80 5526636 [main] git 4640 alloc_sd: Created SD-Size: 176 372 5527008 [main] git 4640 fhandler_base::set_flags: flags 0x100A01, supplied_bin 0x1 50 5527058 [main] git 4640 fhandler_base::set_flags: filemode set to binary 34 5527092 [main] git 4640 fhandler_base::open: 0 = NtCreateFile (0x1F0, 40120080, \??\C:\repo\cvs\abc-git\src\libCpp\services\cdu\flashvm46.cpp, io, NULL, 80, 7, 2, 4020, NULL, 0) 36 5527128 [main] git 4640 fhandler_base::open: 1 = fhandler_base::open (\??\C:\repo\cvs\abc-git\src\libCpp\services\cdu\flashvm46.cpp, 0x100A01) 67 5527195 [main] git 4640 fhandler_base::open_fs: 1 = fhandler_disk_file::open (\??\C:\repo\cvs\abc-git\src\libCpp\services\cdu\flashvm46.cpp, 0xA01) 37 5527232 [main] git 4640 open: 5 = open (src/libCpp/services/cdu/flashvm46.cpp, 0xA01) 35 5527267 [main] git 4640 writev: writev (5, 0x22C424, 1) 33 5527300 [main] git 4640 fhandler_base::write: binary write 129 5527429 [main] git 4640 writev: 4874 = write (5, 0x22C424, 1), errno 2 35 5527464 [main] git 4640 close: close (5) 34 5527498 [main] git 4640 fhandler_base::close: closing '/c/repo/cvs/abc-git/src/libCpp/services/cdu/flashvm46.cpp' handle 0x1F0 115 5527613 [main] git 4640 close: 0 = close (5) 177 5527790 [main] git 4640 normalize_posix_path: src src/libCpp/services/flash.cpp 37 5527827 [main] git 4640 cwdstuff::get: posix /c/repo/cvs/abc-git 34 5527861 [main] git 4640 cwdstuff::get: (/c/repo/cvs/abc-git) = cwdstuff::get (0x10F0008, 32768, 1, 0), errno 0 34 5527895 [main] git 4640 normalize_posix_path: /c/repo/cvs/abc-git/src/libCpp/services/flash.cpp = normalize_posix_path (src/libCpp/services/flash.cpp) 59 5527954 [main] git 4640 mount_info::conv_to_win32_path: conv_to_win32_path (/c/repo/cvs/abc-git/src/libCpp/services/flash.cpp) 49 5528003 [main] git 4640 set_flags: flags: binary (0x2) 34 5528037 [main] git 4640 mount_info::conv_to_win32_path: src_path /c/repo/cvs/abc-git/src/libCpp/services/flash.cpp, dst C:\repo\cvs\abc-git\src\libCpp\services\flash.cpp, flags 0x2, rc 0 86 5528123 [main] git 4640 symlink_info::check: not a symlink 53 5528176 [main] git 4640 symlink_info::check: 0 = symlink.check (C:\repo\cvs\abc-git\src\libCpp\services\flash.cpp, 0x2232B8) (0x2) 34 5528210 [main] git 4640 path_conv::check:
Re: [Fwd: [1.7] wcwidth failing configure tests]
2009/5/13 Corinna Vinschen vinsc...@redhat.com: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c This looks nice. Do you import Markus Kuhn's wcwidth implementation? Trouble is, there's the thorny issue of the CJK Ambiguous Width category of characters, which consists of things like Greek and Cyrillic letters as well as line drawing symbols. Those have a width of 1 in Western use, yet with CJK fonts they have a width of 2. That's why Markus Kuhn's code includes the mk_wcswidth_cjk() variant. We should use the standard variation alone, imho. I don't think so. 1) It is very very inconvenient for me :-) (Now, I apply the local patch of CJK width support to cygwin1.dll in my environment.) 2) Unicode Standard Annex #11 http://www.unicode.org/unicode/reports/tr11/ recommends: 5 Recommendations (snip) When processing or displaying data (snip) Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. The recommendation is independent of legacy encoding. I think that a new locale category that specifies the context is necessary. Because the context influences only the display or text layout. However, there is no such standard now. Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
2009/5/15 Corinna Vinschen corinna-cyg...@cygwin.com: Here's one problem. What if an application uses setenv(LANG, ...)? Oh. Hmmm, I think that anything should not occur. Do you want Cygwin to intercept all calls to setenv() to check for setting $LC_ALL/LC_CTYPE/LANG? No. I think that only setlocale() has to do the check. The reason: - setlocale(LC_CTYPE, C) is called from Cygwin startup. - The following code become valid. setenv(LANG, ...); setlocale(LC_ALL, ); -- IWAMURO Motnori http://vmi.jp/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 15 01:34, IWAMURO Motonori wrote: 2009/5/15 Corinna Vinschen corinna-cyg...@cygwin.com: Here's one problem. What if an application uses setenv(LANG, ...)? Oh. Hmmm, I think that anything should not occur. Do you want Cygwin to intercept all calls to setenv() to check for setting $LC_ALL/LC_CTYPE/LANG? No. I think that only setlocale() has to do the check. The reason: - setlocale(LC_CTYPE, C) is called from Cygwin startup. - The following code become valid. setenv(LANG, ...); setlocale(LC_ALL, ); Ok, that makes sense. I'm just testing a patch which use the environment settings internally as you proposed (still keeping UTF-8 the default for the C locale). So far it works fine, I have just trouble with SJIS, but that's not something I can easily test. I'm simply lacking a real understanding of the SJIS encoding. Maybe you can look into that in the next couple of days? I'll be mostly offline next week and the week after so there's a lot time for testing ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Fwd: [1.7] wcwidth failing configure tests]
On May 15 00:58, IWAMURO Motonori wrote: 2009/5/13 Corinna Vinschen vinsc...@redhat.com: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c This looks nice. Do you import Markus Kuhn's wcwidth implementation? Trouble is, there's the thorny issue of the CJK Ambiguous Width category of characters, which consists of things like Greek and Cyrillic letters as well as line drawing symbols. Those have a width of 1 in Western use, yet with CJK fonts they have a width of 2. That's why Markus Kuhn's code includes the mk_wcswidth_cjk() variant. We should use the standard variation alone, imho. I don't think so. 1) It is very very inconvenient for me :-) (Now, I apply the local patch of CJK width support to cygwin1.dll in my environment.) 2) Unicode Standard Annex #11 http://www.unicode.org/unicode/reports/tr11/ recommends: 5 Recommendations (snip) When processing or displaying data (snip) Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. The recommendation is independent of legacy encoding. I think that a new locale category that specifies the context is necessary. Because the context influences only the display or text layout. However, there is no such standard now. Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. That would be fine with me, but tests for the actual language are not used anywhere in newlib, so that's something very new. Can we check in my patch for the time being and extend it with the CJK variation later? I will not be available for the next two weeks, but I'd be glad if at least the default variation can go in so I can create another Cygwin test release before I'm offline. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin 1.7 setup question
Hi All... In the recent setup discussion, there was objection to administrators.none as the default for setup to use. I'm not suggesting any changes, just asking questions for my own understanding. Would administrators.none cause any security issues on an install? Is setup expected to eventually run postinstall scripts as administrator.administrators instead of administrators.none? Thanks, ...Karl _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
Date: Thu, 14 May 2009 02:38:37 -0700 (PDT) From: Marc Girod marc.girod at gmail dor com Looking at the sources, the most suspicious place given your description, seems to be msdos.c, around lines 4453-4494... msdos.c is not compiled in the Cygwin build. It is only compiled in the MS-DOS (a.k.a. DJGPP) build. (You should be able to verify that there's no msdos.o file in the src/ directory, where you compiled Emacs.) So these lines cannot possibly explain any problems in the Cygwin build of Emacs. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.7 setup question
On May 14 10:38, Karl M wrote: Hi All... In the recent setup discussion, there was objection to administrators.none as the default for setup to use. I'm not suggesting any changes, just asking questions for my own understanding. Would administrators.none cause any security issues on an install? Probably not, except that all local users are member of the None group. If file are created with 775 or 664 permissions (which hopefully no package uses), then every local, authenticated user can change the file. Is setup expected to eventually run postinstall scripts as administrator.administrators instead of administrators.none? It's not running scripts as administrators.none, it's running them as user.users-primary-group. That's None for all local accounts. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
On 5/14/2009 2:48 PM, Eli Zaretskii wrote: Date: Thu, 14 May 2009 02:38:37 -0700 (PDT) From: Marc Girod marc.girod at gmail dor com Looking at the sources, the most suspicious place given your description, seems to be msdos.c, around lines 4453-4494... msdos.c is not compiled in the Cygwin build. It is only compiled in the MS-DOS (a.k.a. DJGPP) build. (You should be able to verify that there's no msdos.o file in the src/ directory, where you compiled Emacs.) That's correct. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: git checkout problem
I've been using git for a few weeks now and recently ran into a problem that I just can't workaround. I tried updating to the cygwin 1.7 release hoping that this would fix the issue but it didn't. I found that a checkout of a branch new_file_system from the master branch (or vice versa) would result an error that a file can't be unlinked. Below is the sequence of git commands that I run that cause the problem. This is the exact sequence of commands that I run: I've performed some additional experiments and I'm starting to believe this is probably not an issue with cygwin (it might be a git on Windows issue). I installed the latest version of msysgit (1.6.3.msysgit.0) and found that I was still having the problem described above. I'm running Windows Vista w/SP1 with UAC enabled. I found that if I turn off UAC the problem went away. Turn UAC on and the problem re-appears. I then tried running bash as an admin and that also seems to resolve the issue. Finally I modified the properties of the bash executable to run in Windows XP w/SP2 compatibility mode and that also seems to resolve this problem even with UAC enabled and running without admin privileges. I'll continue to do some more testing but it appears that I have a reasonable workaround for this issue. - Steve - -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin 1.7 setup question
Date: Thu, 14 May 2009 21:22:23 +0200 From: corinna Subject: Re: Cygwin 1.7 setup question On May 14 10:38, Karl M wrote: Hi All... In the recent setup discussion, there was objection to administrators.none as the default for setup to use. I'm not suggesting any changes, just asking questions for my own understanding. Would administrators.none cause any security issues on an install? Probably not, except that all local users are member of the None group. If file are created with 775 or 664 permissions (which hopefully no package uses), then every local, authenticated user can change the file. Is setup expected to eventually run postinstall scripts as administrator.administrators instead of administrators.none? It's not running scripts as administrators.none, it's running them as user.users-primary-group. That's None for all local accounts. Is this setup behavior expected to stay the same, or eventually run them as administrator.administrators? Thanks, ...Karl _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On May 14 19:23, Corinna Vinschen wrote: On May 15 01:34, IWAMURO Motonori wrote: 2009/5/15 Corinna Vinschen corinna-cyg...@cygwin.com: Here's one problem. What if an application uses setenv(LANG, ...)? Oh. Hmmm, I think that anything should not occur. Do you want Cygwin to intercept all calls to setenv() to check for setting $LC_ALL/LC_CTYPE/LANG? No. I think that only setlocale() has to do the check. The reason: - setlocale(LC_CTYPE, C) is called from Cygwin startup. - The following code become valid. setenv(LANG, ...); setlocale(LC_ALL, ); Ok, that makes sense. I'm just testing a patch which use the environment settings internally as you proposed (still keeping UTF-8 the default for the C locale). So far it works fine, I have just trouble with SJIS, but that's not something I can easily test. I'm simply lacking a real understanding of the SJIS encoding. Maybe you can look into that in the next couple of days? I'll be mostly offline next week and the week after so there's a lot time for testing ;-) I applied the patch. The charset used by Cygwin now only depends on the last call to setlocale in an application and eventually on the setting of the internationalization environment variables LC_ALL/LC_CTYPE/LANG. A side effect of this change is that the console charset depends solely on the environment setting again. So you can change the console charset used in an application on the fly again by changing the LC_ALL/LC_CTYPE/LANG setting in the environment(*), instead of setting it only once at startup of the first Cygwin process in the console. The (in)famous ssh to a remote machine from a UTF-8 console doesn't work problem(**) should be unaffected by this change and still work now, if, for instance, LANG is set to en_US.UTF-8 in the calling shell. Just the documentation needs to be updated again. I really hope this change makes it finally easier to use Cygwin with native characters. I'll create a new Cygwin package tomorrow. Corinna (*) Still depends on a call to setlocale, but the Cygwin shells do that anyway. (**) http://cygwin.com/ml/cygwin/2009-04/msg00055.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
On Wed, May 13, 2009 at 10:06 PM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Lenik on 5/13/2009 7:49 PM: You have it backwards. Forking doesn't break the relocation. Relocation breaks forking. cygwin1.dll needs to have a very special memory layout to implement the fork semantics in Win32. If this memory layout is disrupted, fork breaks. Could you explain in more detail? I can't find any document about this special memory layout. Read the source. This link is a bit old, but still captures the essence: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5content-type=text/x-cvsweb-markupcvsroot=src Remember, the semantics of fork is that BOTH processes (the parent and child) must see the SAME memory, and that includes all shared libraries being mapped at the SAME location. But since Windows doesn't provide a native fork, the child must remap everything that the parent had, and hope that it lands at the same place. Rebasing improves the chance that the child will remap, because there are fewer dlls to be remapped in an arbitrary order. Is this a place where using vfork() instead of fork() helps (where it's applicable, of course)? If so, we might be able to reduce the number of rebase failures in the future just by trying to push other projects to use vfork wherever it's substitutable for fork... ~Matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Debugging a time zone problem
Eli Zaretskii wrote: msdos.c is not compiled in the Cygwin build. Indeed! MS Disk Operative System :-P Cheers, Angelo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Fwd: [1.7] wcwidth failing configure tests]
Corinna Vinschen wrote: On May 15 00:58, IWAMURO Motonori wrote: 2009/5/13 Corinna Vinschen vinsc...@redhat.com: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c This looks nice. Do you import Markus Kuhn's wcwidth implementation? Trouble is, there's the thorny issue of the CJK Ambiguous Width category of characters, which consists of things like Greek and Cyrillic letters as well as line drawing symbols. Those have a width of 1 in Western use, yet with CJK fonts they have a width of 2. That's why Markus Kuhn's code includes the mk_wcswidth_cjk() variant. We should use the standard variation alone, imho. I don't think so. 1) It is very very inconvenient for me :-) (Now, I apply the local patch of CJK width support to cygwin1.dll in my environment.) 2) Unicode Standard Annex #11 http://www.unicode.org/unicode/reports/tr11/ recommends: 5 Recommendations (snip) When processing or displaying data (snip) Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. The recommendation is independent of legacy encoding. I think that a new locale category that specifies the context is necessary. Because the context influences only the display or text layout. However, there is no such standard now. Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. That would be fine with me, but tests for the actual language are not used anywhere in newlib, so that's something very new. Can we check in my patch for the time being and extend it with the CJK variation later? I will not be available for the next two weeks, but I'd be glad if at least the default variation can go in so I can create another Cygwin test release before I'm offline. Corinna, I have no problem with checking the new patch in and extending this later, assuming you have thoroughly tested this implementation. -- Jeff J. Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
On Thu, May 14, 2009 at 05:20:58PM -0400, Matt Wozniski wrote: On Wed, May 13, 2009 at 10:06 PM, Eric Blake wrote: According to Lenik on 5/13/2009 7:49 PM: You have it backwards. Forking doesn't break the relocation. Relocation breaks forking. cygwin1.dll needs to have a very special memory layout to implement the fork semantics in Win32. If this memory layout is disrupted, fork breaks. Could you explain in more detail? I can't find any document about this special memory layout. Read the source. ??This link is a bit old, but still captures the essence: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5content-type=text/x-cvsweb-markupcvsroot=src Remember, the semantics of fork is that BOTH processes (the parent and child) must see the SAME memory, and that includes all shared libraries being mapped at the SAME location. ??But since Windows doesn't provide a native fork, the child must remap everything that the parent had, and hope that it lands at the same place. ??Rebasing improves the chance that the child will remap, because there are fewer dlls to be remapped in an arbitrary order. Is this a place where using vfork() instead of fork() helps (where it's applicable, of course)? If so, we might be able to reduce the number of rebase failures in the future just by trying to push other projects to use vfork wherever it's substitutable for fork... In Cygwin vfork == fork. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: We can't say it enough: Read the source. Is this a place where using vfork() instead of fork() helps (where it's applicable, of course)? If so, we might be able to reduce the number of rebase failures in the future just by trying to push other projects to use vfork wherever it's substitutable for fork... In Cygwin vfork == fork. But, if you really wanted to be nice, instead of forcing us to respond to your uneducated guesses, you could implement posix_spawn, and push for more upstream projects (particularly bash) to use it. That is at least one case where people have already implemented posix_spawn on top of fork (and in fact, gnulib has already done so, and m4 uses the gnulib implementation), but where you can also implement it more efficiently on top of native windows semantics if you do it right. And maybe, in the process of seeing how many loose ends there are to get it to have posix_spawn work correctly, you will start to understand why we haven't already implemented it, and why cygwin does fork/vfork the way it does. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
On Thu, May 14, 2009 at 11:23:08PM +, Eric Blake wrote: Christopher Faylor writes: We can't say it enough: Read the source. Is this a place where using vfork() instead of fork() helps (where it's applicable, of course)? If so, we might be able to reduce the number of rebase failures in the future just by trying to push other projects to use vfork wherever it's substitutable for fork... In Cygwin vfork == fork. But, if you really wanted to be nice, instead of forcing us to respond to your uneducated guesses, you could implement posix_spawn, and push for more upstream projects (particularly bash) to use it. That is at least one case where people have already implemented posix_spawn on top of fork (and in fact, gnulib has already done so, and m4 uses the gnulib implementation), but where you can also implement it more efficiently on top of native windows semantics if you do it right. And maybe, in the process of seeing how many loose ends there are to get it to have posix_spawn work correctly, you will start to understand why we haven't already implemented it, and why cygwin does fork/vfork the way it does. Yes. What he said. I meant to reiterate the Read the source advice. It really isn't very polite to keep asking us to explain things to you when 1) any reasonable person would conclude that most of these issues had already been discussed to death and 2) there is source code available. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Selling management on Cygwin
Chap Harrison wrote: I work for a 5-person company whose IT infrastructure is exclusively Windows Server-based, and whose mindset is very narrowly Microsoftian. I prefer *nix. Four months ago I quietly created a Windows Server 2003 machine running in a VM on a test box, installed Cygwin, and have been successfully writing running tools (mostly Perl) all this time. Proven track record of productivity! One feather for your cap and/or argument... Now I want to persuade management to let me install Cygwin directly on the main Server 2003 box. This is not only for better interactive performance (I work remotely and need to go through one extra screen-scraper layer to get to my current Cygwin command line), but also to access some directories on the main box that aren't being shared and, consequently, can't be accessed from my current Cygwin. Have you thought about the ... better to ask for forgiveness than to ask for permission... approach? It works wonders! Cygwin accessing shares on the main box can be done without installing Cygwin on the main box. They just need to be shared then Cygwin can //mainbox/share/file... I expect to be met with plenty of FUD. I honestly don't know what kind of concerns arguments will be raised, but I feel certain they will be garden variety. However, since I'm not a management or IT type, nor a Windows expert, nor a Cygwin expert, I am unprepared to argue the case. Well why don't you first propose it and see if there are any objections. Then deal with them. Common objections are the ever so popular Well it's different argument. You could explain to them that if they are uncomfortable using it they don't need to. Another big one that sometimes is thought but not mentioned revolves around licensing concerns. I assume you are not proposing to stick Cygwin in your product. If not then licensing not an issue. Tell them, Licensing is not an issue as long as we don't incorporate Cygwin into our end product. I'm not proposing that we do that, rather I'm proposing that we utilize Cygwin internally for our own internal tasks to produce our product. That requires no licensing. If someone could help, perhaps by briefly explaining what it is they're worried about, and why they needn't be, I would greatly appreciate it. Alternately, a link to an article would be nice (I haven't found any so far). What they'll be worried about typically is 1) it's foreign, different and 2) it might get them in trouble licensing-wise or somehow require them to GPL their own stuff, I've addressed those common objections above. In some ways this is more of an issue about open source software in general, but I'm sure there will be questions specifically about Cygwin and the extent to which it touches Windows OS innards. Any guidance would be helpful! Cygwin doesn't really touch Windows OS innards much at all. In fact there's no uninstall! Generally uninstall is simply remove C:\Cygwin and you're done. Oh and there is a small section of the registry that if you wanted to be super tidy you could remove. Aside from that, unless you set up services such as ssh, cron, etc - which will make service entries in the registry and/or possibly create a sshd_server user, there's really no mucking with Windows OS innards. -- Andrew DeFaria http://defaria.com How do you tell when you run out of invisible ink? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Selling management on Cygwin
Jason Pyeron wrote: Semi-light hearted, semi-jabbing responses follow... Please note, none of these issues are meant to imply that other solutions do not have these issues, these are just some of the issues we have received from customers' management about tools, including Cygwin. OOS: * Licensing Licensing shouldn't be an issue unless you incorporate Cygwin in your resulting product and are trying to sell it. * IP liability assurance / indemnification I'll let the lawyers have at it on that one... * Entity backed product lifecycle and migration. Not sure what you mean here... Support: * Who supports it, contracted terms. Honestly, who supports Windows? By that I mean, have you ever personally called Microsoft regarding a Windows product and have gotten support? I know I never have - in 25 years. This goes for many, many other products both commercial and open source. In fact I get more support, better, quicker, etc. from open source stuff. * Warranty Ah... what fer? * Other vendors will not support the system if you install it. Shh! Don't tell them! (Mainly because it's largely irrelevant). CM: * Feature Stability IMHO Cygwin is pretty dern stable. * Interoperability testing (and costs associated of doing something new) Right, like when companies install Visual Studio or some other paid for product they run extensive interoperability test suites before rolling them out! I assure you, at least where I've been - and I've participated in many roll outs - they don't. Security: * Who guarantees safety The same people who guarantee the safety of Outlock that most corporate IT depts insist that you use! And we all know that Lookout has never been known to cause any security problems... ;-) * Foreign national/government written code Again, huh? Not sure how this is relevant... * disclosure of vulnerabilities With open source you can disclose your own vulnerabilities simply by looking at the source. Again, I meant this to be light hearted and a little jabbing. I understand the corporate concerns. But I've also been in the trenches long enough to know that the concerns, while perhaps well founded, are not applied equally nor fairly or that they really don't make sense in the practical world. YMMV. -- Andrew DeFaria http://defaria.com Boycott shampoo! Demand the REAL poo! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.5] Problem with OpenSSH on Windows Home Server (Win2003)
I've installed cygwin 1.5 on my WHS box as Administrator. I've opened a cygwin terminal and executed the mkpasswd -l /etc/passwd and mkgroup -l /etc/group commands, executed ssh-host-setup and used privilege separation, and everything seems to have executed OK. I can ssh to that machine as Administrator just fine using password auth. However, I can't ssh in as any other user on that machine using password authentication - I get told that the password is incorrect, which I know it isn't. I can use key-based auth to login as any user, so I do have a workaround, but I'm curious as to why no user but Administrator can use password auth to log in? I've logged in via remote desktop as the user I wish to SSH as and ran ssh-user-config as that user (that's how I got the key-based login working). I haven't done that as Administrator, though, and it still lets me log in just fine there. Sorry if this is a bit rambling, but I've been working on this problem for a while and it's getting late where I am... cygcheck.out is attached. Cygwin Configuration Diagnostics Current System Time: Fri May 15 00:15:46 2009 Windows 2003 Server Ver 5.2 Build 3790 Service Pack 2 Path: c:\cygwin\usr\local\bin c:\cygwin\bin c:\cygwin\bin c:\cygwin\usr\X11R6\bin c:\Program Files\Windows Resource Kits\Tools\ c:\php c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\MySQL\MySQL Server 5.0\bin c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\cygwin\bin c:\cygwin\bin Output from c:\cygwin\bin\id.exe (nontsec) UID: 1022(duckpuppy)GID: 513(None) 513(None) 550(Print Operators) 555(Remote Desktop Users) 545(Users) 1014(RW_3) 1008(RW_4) 1016(RW_5) 1012(RW_6) 1020(RW_7) 1018(RW_B) 1033(RW_J) 1044(RW_O) 1047(RW_P) 1021(Windows Home Server Users) Output from c:\cygwin\bin\id.exe (ntsec) UID: 1022(duckpuppy)GID: 513(None) 513(None) 550(Print Operators) 555(Remote Desktop Users) 545(Users) 1014(RW_3) 1008(RW_4) 1016(RW_5) 1012(RW_6) 1020(RW_7) 1018(RW_B) 1033(RW_J) 1044(RW_O) 1047(RW_P) 1021(Windows Home Server Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'duckpuppy' PWD = '/home/duckpuppy' CYGWIN = 'ntsec' HOME = '/home/duckpuppy' MAKE_MODE = 'unix' HOMEPATH = '\cygwin\home\duckpuppy' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' HOSTNAME = 'speedforce' TERM = 'xterm' SHELL = '/bin/bash' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 12 Stepping 0, AuthenticAMD' WINDIR = 'C:\WINDOWS' SSH_CLIENT = '192.168.1.40 50424 22' OLDPWD = '/home/duckpuppy' USERDOMAIN = 'SPEEDFORCE' SSH_TTY = '/dev/tty2' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/cygdrive/c/DOCUME~1/CYG_SE~1/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'cyg_server' PROCESSOR_LEVEL = '15' MAIL = '/var/spool/mail/duckpuppy' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\duckpuppy.SPEEDFORCE' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SPEEDFORCE' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'c:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' LOGNAME = 'duckpuppy' TMP = '/cygdrive/c/DOCUME~1/CYG_SE~1/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Microsoft XPS Document Writer' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0c00' SSH_CONNECTION = '192.168.1.40 50424 192.168.1.2 22' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' COMPUTERNAME = 'SPEEDFORCE' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin (default) = 'Administrator;duckpuppy;renee' HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'c:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'c:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'c:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 20481Mb 36% CP CS UN PA FC SYS d: hd NTFS361062Mb 49% CP CS UN PA FC DATA x: cd
