Re: sourceware.org downtime
Christopher Faylor wrote: If you were subscribed to this list you should have received email telling you that sourceware.org (aka cygwin.com/gcc.gnu.org) was down. As you can see, we are now back up again. We had a hard disk failure which was exacerbated by faulty RAID firmware. Putting a new disk into the array caused massive system corruption. We're back online now, running from backups that are less than 24 hours old. The RAID firmware has been updated and we've verified that this problem should not reoccur. Running from backups means that we've jumped back in time so if you've subscribed or unsubscribed from this list and now are either not getting or getting it, that's why. Also any package maintainers who released packages last Thursday (2005-02-03) or Wednesday (2005-02-02) should double check that their packages are still there. And now to bed. cgf For the record, I'd like to congratulate you and the other overseers/admins four your incredibly quick response time. You guys gals are obviously doing a great job, and you've proven it once again. Thanks! rlc
Re: bash: tab completion failure from (but not at) /
Corinna Vinschen wrote: On Feb 8 07:19, [EMAIL PROTECTED] wrote: Recent remarks (I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released) suggest that an updated cygwin1.dll might be imminent. Please could I mention a minor but annoying glitch described along with Corinna's immediate and effective fix at http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has re-emerged in recent snapshots, at least since http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna records her perplexity (weird) at this re-emergence. Things worked properly in snapshot 20041222 but fail from 20041223. Nevertheless, that's a bash problem. Is our bash maintainer still around? Yep, still here.. I'll have a look at what your patch in Bash is up to tomorrow (still don't have a Windows machine at home) but it should be compiled in - there's no reason why it wouldn't be: the only thing I haven't changed is a fix for http://cygwin.com/ml/cygwin/2004-09/msg01517.html. I'll report back when I've checked (ping me if that doesn't happen in 24 hours - I'm rather busy lately...) rlc -- 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/
[ANNOUNCEMENT] Available for testing: Bash 2.05-17
New News: = Version 2.05b-17 of the Bash package is now available for download. This is a bugfix release relative to 2.05b-16, and fixes the bug discussed in a thread starting here: http://cygwin.com/ml/cygwin/2004-09/msg00781.html To update your installation: === Run the Setup utility from http://cygwin.com/setup.exe and pick up the proper packages. Note that as this Bash version is a *test* version. Problem reports: === Please send reports of any problems related to these packages to [EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a regular basis. Remaining issues: The issue reported in http://cygwin.com/ml/cygwin/2004-09/msg01517.html still exists and is not fixed in this version. Before applying the suggested change, I will have to make sure there are no side-effects we don't want.. Old News: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. Port Notes: == - version 2.05b-17 - Applied a patch provided by Pierre Humblet, fixing the PID re-use issues, originally reported in the thread Bash returns incorrect process status. The final patch applied has not been posted to [EMAIL PROTECTED] but closely resembles the one posted in http://sources.redhat.com/ml/cygwin/2004-10/msg01093.html -- Also applied a patch provided by Corinna Vinschen: * bashline.c (bash_directory_completion_hook): avoid turning '/' into '//' when converting/checking path This patch specifically avoids a problem with tab-completion on some never- released Cygwin versions (some snapshots between versions 1.5.9 and 1.5.10) but more generally fixes a bug introducing ambiguity as to what directory to open and search when asking for root. - version 2.05b-16 - Applied a patch provided by cgf: * subst.c (command_substitute): Guard against opening a pipe handle in stdin/stdout/stderr since they may be closed and keeping the pipe handle open in a subprocess will cause hangs. - version 2.05b-15 - Applied a temporary patch to fix the problem reported in http://www.cygwin.com/ml/cygwin/2003-09/msg00822.html - version 2.05b-14 - Additional canonical patches 5 through 7 applied - version 2.05b-13 and earlier - Earlier versions were maintained by Corinna Vinschen. The history may be found in the cygwin-announce archives. -- 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/
Available for testing: Bash 2.05-17
New News: = Version 2.05b-17 of the Bash package is now available for download. This is a bugfix release relative to 2.05b-16, and fixes the bug discussed in a thread starting here: http://cygwin.com/ml/cygwin/2004-09/msg00781.html To update your installation: === Run the Setup utility from http://cygwin.com/setup.exe and pick up the proper packages. Note that as this Bash version is a *test* version. Problem reports: === Please send reports of any problems related to these packages to [EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a regular basis. Remaining issues: The issue reported in http://cygwin.com/ml/cygwin/2004-09/msg01517.html still exists and is not fixed in this version. Before applying the suggested change, I will have to make sure there are no side-effects we don't want.. Old News: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. Port Notes: == - version 2.05b-17 - Applied a patch provided by Pierre Humblet, fixing the PID re-use issues, originally reported in the thread Bash returns incorrect process status. The final patch applied has not been posted to [EMAIL PROTECTED] but closely resembles the one posted in http://sources.redhat.com/ml/cygwin/2004-10/msg01093.html -- Also applied a patch provided by Corinna Vinschen: * bashline.c (bash_directory_completion_hook): avoid turning '/' into '//' when converting/checking path This patch specifically avoids a problem with tab-completion on some never- released Cygwin versions (some snapshots between versions 1.5.9 and 1.5.10) but more generally fixes a bug introducing ambiguity as to what directory to open and search when asking for root. - version 2.05b-16 - Applied a patch provided by cgf: * subst.c (command_substitute): Guard against opening a pipe handle in stdin/stdout/stderr since they may be closed and keeping the pipe handle open in a subprocess will cause hangs. - version 2.05b-15 - Applied a temporary patch to fix the problem reported in http://www.cygwin.com/ml/cygwin/2003-09/msg00822.html - version 2.05b-14 - Additional canonical patches 5 through 7 applied - version 2.05b-13 and earlier - Earlier versions were maintained by Corinna Vinschen. The history may be found in the cygwin-announce archives.
Please upload bash-2.05b-17
Hello, I've rolled up a new *test* version of Bash: bash-2.05b-17. Here's the info: c71afc4cde07a18868d76f3a19b75c34 *bash-2.05b-17-src.tar.bz2 7c2f962718bf072af97ad505116cfaa8 *bash-2.05b-17.tar.bz2 http://rlc.unsane.co.uk/bash-2.05b-17-src.tar.bz2 http://rlc.unsane.co.uk/bash-2.05b-17.tar.bz2 This is a test version because there is one debug output remaining. The conditions for it should basically never happen, but as long as it's there, I don't think this should become canonical. Please upload these and let me know so I can send an announcement. (Do we announce test versions on cygwin-announce, by the way? If not, I'll just send a message to cygwin proper) Thanks, rlc _ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: Please upload bash-2.05b-17
Christopher Faylor wrote: On Fri, Oct 29, 2004 at 02:24:25PM -0400, Ronald Landheer-Cieslak wrote: snip This is a test version because there is one debug output remaining. The conditions for it should basically never happen, but as long as it's there, I don't think this should become canonical. Please upload these and let me know so I can send an announcement. (Do we announce test versions on cygwin-announce, by the way? If not, I'll just send a message to cygwin proper) Sometimes we do, sometimes we don't. I think I may have asked that test versions not get sent to cygwin-announce at some point in the dim past but I don't see why it shouldn't be up to the package maintainer's discretion. In this case, I think it is important enough to reach as wide an audience as possible so I think it should go to cygwin-announce. OK, will do :) Thanks, rlc _ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
RE: Maintainers and cygwin-apps subscriptions
Dario Alcocer wrote: I'm maintaining two packages, and I know that one of the requirements is that I must be subscribed to cygwin-apps. However, the e-mail is easier to read if I use GMANE instead. Can I unsubscribe from cygwin-apps and still maintain the packages? I would still keep up with cygwin-apps, using GMANE instead of e-mail to do so. AFAIK, if you're subscribed to cygwin-apps-allow you can post to cygwin-apps. How you want to read cygwin-apps is up to you. Until this bash vs. bashdb vs. bash-3 stuff came along, I watched cygwin-apps from Gmane as well - and my ronald@ account is a bit blinky on where it can mail.. IMO, the important thing is to keep up with cygwin-apps and cygwin proper in some way. How you do it is up to you. rlc PS: of course, if someone important like cgf or corinna has an opposing opinion, you'd better listen to them than to me :) _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Bash updates, bashdb, bash_completion, etc.
Hello all, Let me just start by saying that I really think bashdb would be a nice addition to Cygwin. That said, I'll need some convincing to add it to mainline Bash as I don't want to maintain YA out-of-tree patch for Bash if I can help it. As for Bash-2.05b-17: I've applied Pierre's patch to bash-2.05b-16 and am compiling it now (I've got a coffee break I can use for that). As for Bash-3: it doesn't currently get through the tests and I do not have the time at the moment to figure out why not. The reason for this is very simple: I don't have a Windows machine at home so all I have for testing is my lunch and coffee breaks. (This same lack of a Windows machine had a rather dramatic impact on the time I had allocated for the Cygwin project a while ago, when I was at home for nearly four consecutive months.. donations are welcome ;) Reini, if you still intend to package bashdb and bash_completion, I'll be happy to work with you to integrate them into the bash package. However, as you have already stated that you don't want to maintain bash and I have already stated that I don't want to maintain bashdb or bash_completion, we'll have to find some solution to this or accept a stalemate. Please feel free to mail me privately about this. rlc PS: I've subscribed this (hotmail) address to cygwin-apps as I don't have E-mail at home either and the Gmane equivalent of this list doesn't allow posting. There's no need to copy to [EMAIL PROTECTED] or to this address.. _ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: Bash returns incorrect process status
Dolton Tony AB wrote: I've noticed that bash doesn't get issued too often. It doesn't for three reasons: 1. the maintainer for Cygwin (that would be me) is very busy 2. The current version of Bash is very, very stable 3. I'm hesitant (reluctant, even) to let a new release of Bash go out the door without proper testing, even if it does fix a bug reported on this list every-so-often - i.e. I don't jump on every patch to apply it tout-de-suite and send out a new release: there's too much that depends on Bash.. That, and reason #1.. As soon as I have the time, I will test and release a new Bash-2 with the two patches I have for it now: one that fixes a problem that occured in a snapshot a while back and shouldn't even bother the every-day Bash user at the moment but is worth a fix anyway (and for which a patch was kindly provided by Corinna) and one that came out of this very thread. As for Bash-3: until I have the time to test it properly (==thouroughly) there won't be a release of it yet and when it comes, it will be a test version. rlc -- 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: bash 3
Pierre A. Humblet wrote: Hello Ronald, Hello Pierre, What are the plans to have bash 3 on Cygwin? I've compiled it and rolled up a package as soon as it was released, but I haven't had time to test it yet - at all. In any case, it will be released as a test package first, but only when I've had at least a chance to test it on the one Windows machine I have at my disposal. My fixes for the pid reuse problems need to be cleaned up, but given that bash 3 is on the horizon I am reluctant to sink any more time in the current version. I've been following the discussion but, regrettably, I really don't have the time at the moment (the problem being, mostly, that when I do have a little time, I only have a Debian Sarge machine.. Things should cool down a bit in the following week or so. If they do, I'll try to release a bash-2.95b with the patch from Corinna that I still have pending and a bash-3.00 with your patch as test. It also seems worthwhile to issue a new release of the current bash with my patches (at least a test version). I have had extra private feedback that they work. I agree. The thing I want to be sure of, though, is that things like configure scripts etc. still work (I know: they run Ash on Cygwin, but still..) - i.e. that there are no compatibility problems between Bash-2 and Bash-3. Bash is probably the most widely-used Bourne-compatible shell out there, so I'm a bit reluctant to just throw the latest and greatest at the Cygwin community without proper testing.. rlc NB: I've Cc-ed the -apps list: I guess this should be on-topic there.
Re: [ITP] e2fsprogs, e2fsimage
Robb, Sam wrote: Hello, I am interested in packaging and maintaining e2fsprogs for Cygwin. Version 1.35 pretty much builds OOTB. My primary interest in e2fsprogs is not the utilities themselves, but the ext2 libraries that are built as part of the package. These ext2 libraries are a pre-requisite for another package that I would like to contribute, e2fsimage. With the ext2 libs from e2fsprogs-1.35 built and installed, e2fsimage also pretty much builds OOTB, and is able to create a basic ext2 filesystem image based off of a Cygwin directory. I've placed both these packages in the Devel category, because they are primarily intended for use by folks using Cygwin as a host platform for cross-development. If folks would prefer it, I could see about packaging and installing e2fsprgs as two seperate components - e2fslibs, and e2fsprogs, for example. e2fslibs could be packaged now, e2fsprogs in the future (when I actually have a chance to test against a real ext2 partition on a Windows box). -Samrobb setup.hint for e2fsprogs: category: Devel requires: cygwin sdesc: Ext2 filesystem utilities ldesc: The Ext2 Filesystem Utilities (e2fsprogs) contain all of the standard utilities for creating, fixing, configuring, and debugging ext2 filesystems. setup.hint for e2fsimage: category: Devel requires: cygwin, e2fsprogs sdesc: Utility for creating ext2 filesystem images. ldesc: e2fsimage enables the user to create and populate an ext2 filesystem image as a copy from an existing directory tree. It supports regular files, directories, soft links, hard links, and block/char special devices. +1 vote rlc
Re: Bash-3.0 available for FTP
FWIW, I'll try to wrap up a Cygwin package with this ASAP (i.e.: when I have time). rlc -- 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/
Slight problem with case sensitivity on managed mounts with CVS-1.11.6
Hello CVS maintainer (et al.), I've got a slight problem with CVS when running it on a directory mounted in managed mode: the directory being case-sensitive, ``cvs update'' should *IMHO* not warn about a file whose name might clash with another due to its case (and on ``cvs checkout'', it doesn't). The file in question is called Hash.h, which has a little brother called hash.h. The error is emitted on line 1809 of src/client.c, which also contains a lengthy comment on why the error may be emitted, confirming my hypothesis. My question is not: please fix this.. - my question is whether you'd be interested in a fix. The fix would consist of * checking whether the file being updated is on a managed mount (don't know how to do that yet, but I assume it's possible) + if so, assume case-sensitivity - if not, assume case-insensitivity The patch would probably be Cygwin-specific, so I doubt it would be possible to get it up-stream, but I'll try to make it as clean as possible.. I should also note that I have *no* ETA on this: it'll be an during-lunch-breaks thing - my question is just whether you'd be interested at all (otherwise, I'll ignore the warning and bite my nails in stead of scratching this particular itch). rlc -- 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: Slight problem with case sensitivity on managed mounts with CVS-1.11.6
Christopher Faylor wrote: On Thu, Jul 22, 2004 at 10:27:38AM -0400, Ronald Landheer-Cieslak wrote: Hello CVS maintainer (et al.), I've got a slight problem with CVS when running it on a directory mounted in managed mode: the directory being case-sensitive, ``cvs update'' should *IMHO* not warn about a file whose name might clash with another due to its case (and on ``cvs checkout'', it doesn't). The file in question is called Hash.h, which has a little brother called hash.h. The error is emitted on line 1809 of src/client.c, which also contains a lengthy comment on why the error may be emitted, confirming my hypothesis. My question is not: please fix this.. - my question is whether you'd be interested in a fix. The fix would consist of * checking whether the file being updated is on a managed mount (don't know how to do that yet, but I assume it's possible) + if so, assume case-sensitivity - if not, assume case-insensitivity Why not send the comment and your hypothesis here rather than informing everyone that there is a comment and asking if anyone would be interested in a fix? I don't think many people would be interested in downloading the sources for cvs to see what you're talking about. From your description it is difficult to tell if your problem is with cygwin managed mounts or with cvs. OK, the problem is with CVS - the managed mounts are working properly. CVS assumes Cygwin is/runs on a case-insensitive (file)system, which is usually the case. On managed mounts, however, the assumption fails, and CVS complains about conflicts in file names that do not exist. (I thought this was clear from the original post, but apparently, that was not the case..) The comment says this: /* This error might be confusing; it isn't really clear to the user what to do about it. Keep in mind that it has several causes: (1) something/someone creates the file during the time that CVS is running, (2) the repository has two files whose names clash for the client because of case-insensitivity or similar causes, See 3 for additional notes. (3) a special case of this is that a file gets renamed for example from a.c to A.C. A cvs update on a case-insensitive client will get this error. In this case and in case 2, the filename (short_pathname) printed in the error message will likely _not_ have the same case as seen by the user in a directory listing. (4) the client has a file which the server doesn't know about (e.g. ? foo file), and that name clashes with a file the server does know about, (5) classify.c will print the same message for other reasons. I hope the above paragraph makes it clear that making this clearer is not a one-line fix. */ A wee bit further digging brings us to the isfile() function, of which diverse versions exist in the code. The solution would seem to be to * either write a Cygwin-specific one or * choose the right one to use The patch would probably be Cygwin-specific, so I doubt it would be possible to get it up-stream, but I'll try to make it as clean as possible.. That seems to imply that the problem is with cvs since any fix to cygwin would be cygwin-specific. If that is the case, then any fix should probably go upstream. Yes, the problem is with CVS, not with Cygwin. Personally, I though the first paragraph of the original post made that clear - apparently, it didn't, so I apologize. Also, the post was primarily intended for the CVS maintainer, whom I assumed has the source already and could trivially look up the file src/client.c. That being said, the comment in question is of no importance to my question: my question being I found an itch in CVS: this is the itch, would you like me to scratch it? the details of the scratching would only be interesting if there were any interest in the scratching itself were interesting.. rlc -- 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: Slight problem with case sensitivity on managed mounts with CVS-1.11.6
Ronald Landheer-Cieslak wrote: Christopher Faylor wrote: On Thu, Jul 22, 2004 at 10:27:38AM -0400, Ronald Landheer-Cieslak wrote: Hello CVS maintainer (et al.), I've got a slight problem with CVS when running it on a directory mounted in managed mode: the directory being case-sensitive, ``cvs update'' should *IMHO* not warn about a file whose name might clash with another due to its case (and on ``cvs checkout'', it doesn't). The file in question is called Hash.h, which has a little brother called hash.h. The error is emitted on line 1809 of src/client.c, which also contains a lengthy comment on why the error may be emitted, confirming my hypothesis. My question is not: please fix this.. - my question is whether you'd be interested in a fix. The fix would consist of * checking whether the file being updated is on a managed mount (don't know how to do that yet, but I assume it's possible) + if so, assume case-sensitivity - if not, assume case-insensitivity Why not send the comment and your hypothesis here rather than informing everyone that there is a comment and asking if anyone would be interested in a fix? I don't think many people would be interested in downloading the sources for cvs to see what you're talking about. From your description it is difficult to tell if your problem is with cygwin managed mounts or with cvs. OK, the problem is with CVS - the managed mounts are working properly. CVS assumes Cygwin is/runs on a case-insensitive (file)system, which is usually the case. On managed mounts, however, the assumption fails, and CVS complains about conflicts in file names that do not exist. (I thought this was clear from the original post, but apparently, that was not the case..) The comment says this: /* This error might be confusing; it isn't really clear to the user what to do about it. Keep in mind that it has several causes: (1) something/someone creates the file during the time that CVS is running, (2) the repository has two files whose names clash for the client because of case-insensitivity or similar causes, See 3 for additional notes. (3) a special case of this is that a file gets renamed for example from a.c to A.C. A cvs update on a case-insensitive client will get this error. In this case and in case 2, the filename (short_pathname) printed in the error message will likely _not_ have the same case as seen by the user in a directory listing. (4) the client has a file which the server doesn't know about (e.g. ? foo file), and that name clashes with a file the server does know about, (5) classify.c will print the same message for other reasons. I hope the above paragraph makes it clear that making this clearer is not a one-line fix. */ A wee bit further digging brings us to the isfile() function, of which diverse versions exist in the code. The solution would seem to be to * either write a Cygwin-specific one or * choose the right one to use The patch would probably be Cygwin-specific, so I doubt it would be possible to get it up-stream, but I'll try to make it as clean as possible.. That seems to imply that the problem is with cvs since any fix to cygwin would be cygwin-specific. If that is the case, then any fix should probably go upstream. Yes, the problem is with CVS, not with Cygwin. Personally, I though the first paragraph of the original post made that clear - apparently, it didn't, so I apologize. Also, the post was primarily intended for the CVS maintainer, whom I assumed has the source already and could trivially look up the file src/client.c. That being said, the comment in question is of no importance to my question: my question being I found an itch in CVS: this is the itch, would you like me to scratch it? the details of the scratching would only be interesting if there were any interest in the scratching itself were interesting.. Actually, upon some more investigation it looks like the problem is not in isfile(), but in the fact that isfile() is even called: it is only called for this potentially conflicting file.. I guess I'm scratching ;) rlc -- 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: Facing problem with bash
Atukuri, Vasudeva_Kumar wrote: OS: Windows 2000 Cygwin bash version 2.05b.0(9) My application is a combination of Fortran and C. In Fortran Stdout's number is 6. When I ran the application from the Cygwin console it is giving the problem and exited. where there is a write statement to the stdout. * Input/Output Error 179: Bad file descriptor In Procedure: openwt At Line: 562 Statement: Formatted WRITE Unit: 6 Connected To: Stdin End of diagnostics * And then I typed the command bash (gone into one more level deeper), then it worked. And tried again one more step deeper ($SHLVL = 3) it gave the same problem. I kept on going deeper and deeper and my observation is... For all odd SHLVL values it is failing(giving the above error message) For all even SHLVL values it is succeeding. The strange thing is when I ran from the remote shell. My rsh shell is set to use /usr/bin/bash I ran the application on remote shell (using rsh) then the application is running properly. In all levels of SHLVL, it is running properly. Can you please suggest us a solution to solve this problem? Ehm... Not knowing squat about Fortran, I have not the slightest idea what you're talking about, nor what your problem is.. I'm tempted to say http://www.catb.org/~esr/faqs/smart-questions.html or perhaps http://cygwin.com/problems.html Could you perhaps post a minimalist test case that shows the problem (i.e. a Fortran source file, a Makefile and whatnot so I can simply type `make' and have the problem occur?) As I said, I don't know *anything* about Fortran, but if your problem is really with Bash, I'll be happy to help.. rlc Cygwin Bash maintainer (among other things). -- 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: Slight problem with case sensitivity on managed mounts with C VS-1.11.6
Dave Korn wrote:
My ${CURRENCY_UNIT}*1e-2: rather than guessing, cvs should *find out*, by
creating a file in the current directory using a name that is known not to
exist, try to unlink it using a shifted version of that name, and then see
if it's gone or not. I *think* that would do the job, wouldn't it?
Um, yes, but IMHO that would be a hack - mostly because it'd have to do
that in every subdir in the tree, as it can't know for sure any other
way for the subdir in question (for all it knows, different stuff might
be mounted in /foo/bar wrt /foo (or /foo/bar/.. for that matter).
The problem I'm facing is Cygwin-specific. I *think* it is rather
uncommon as a problem outside the Cygwin-powered world, so I'd opt for a
Cygwin-specific solution in the same direction as the other
platform-specific solutions in CVS as implemented..
Just my two HFL 0.02.. ;)
rlc
PS [OT]: HFL 0.02 hasn't been dispensible in valid currency since the
mid-80s, when the currency that had a value of HFL 0.01 went the way of
the dodo; the HFL (dutch guilder) is nostalgically missed since the
introduction of the Euro, which became the *only* acceptable currency in
The Netherlands on 2002-02-17. HFL 0.02 was then mapped to EUR 0.01,
which is about CAN 0.02, which would have been about HFL 0.04 ;)
--
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: home directory.
Vince Hoffman wrote: On Wed, 16 Jun 2004, Chris W wrote: It seems that somewhere $HOME is getting set to /cygdrive/c. I want it to be /home/$USER like the /etc/profile would set it to if it wasn't already set to /cygdrive/c. So where do I change that? Have a look at your windows environment variables. (type set from a windows command prompt) or to see and change them (if on 2k/xp not sure for 9x its been too long,) right click my computer, select properties, then select the advanced' tab, then select environment variables. When you've done that, if HOME is set there, some program you've already installed probably needs it for something. You should probably edit your cygwin.bat to set it to something more appropriate for Cygwin and leave the one in your Windows environment alone.. Unless, of course, you know what you're doing and/or you want to use Cygwin applications that use the HOME environment variable outside of the shell presented by cygwin.bat, in which case your Windows settings is what you want to change.. HTH rlc -- 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: .bashrc is ignored
Hoss wrote: I'm a newbie to cygwin and I'm trying to setup .bashrc to start when I launch a cygwin terminal (using rxvt in fact). my .bashrc is ignored which I think is because the %HOME% environment variable is not set *before* I run bash/rxvt. When I do set it, it simply causes bash to create new directories. Basically I'm not sure whether %HOME% (a windows environment variable) should be set in Windows or POSIX format, and how to quote the string or escape spaces in either case - I'm trying to make sure my home directory is the same as my windows profile directory (done this) and that bash recognises this as the location to find .bashrc. Hello Hoss, Could you please provide a bit more information, such as: * the contents of your cygwin.bat file (or rather: how you invoke rxvt and make it invoke Bash * the result of typing ``echo $HOME'' (without the quotes) on the Bash command- line. * the output of cygcheck as described at http://cygwin.com/problems.html (attached, not in-line) I.e., there's not enough information in your mail to know how to help you: it could be that your HOME variable is not set correctly, though your mention of the fact that your home directory actually is the directory you want it to be does not support that; it could also be that you don't invoke Bash correctly for it to read your ~/.bashrc file - i.e. ~/.bashrc is only read if the shell is not a login shell (i.e. the option ``--login'' is not used) and it is interactive (and the option ``--no-rc'' is not used either). If the shell you're using is a login shell, the file Bash looks for is ~/.profile, which *usually* (but by no means always) sources the ~/.bashrc file, but it is up to the user to make it so. More details about how Bash behaves when it starts up and which files it reads can be found in the INVOCATION section in Bash' manpage. rlc pgp0.pgp Description: PGP signature
Status on coreutils? (was: Re: ITP moratorium still in effect?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Pechtchanski wrote: | The latest on coreutils is that it's still not ready to go mainstream | (http://cygwin.com/ml/cygwin-apps/2004-03/msg00150.html). What is the current status on this? I still have it in my ITP queue and my Bugzilla is starting to whine about it, but if there's another ITP that is ready to go mainstream, I'll be happy to kick it out of my queue and be done with it ;) If there's no progress, I'll use the little time I have a Windows computer next to me on my desk to work on coreutils rather than example programs for Cygwin-docs (should have a Windows box this afternoon). rlc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAbDeOU1nODpimgXsRAsTWAKCsNCUEo5QnLBO3fYY/sc0KSo7siwCgofV0 EVl4J/U/lw+D54+BbK6Wy7w= =7vzt -END PGP SIGNATURE-
Re: On forming a SC [was Re: ITP moratorium still in effect?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: | On Sun, Mar 28, 2004 at 04:02:55PM -0500, Nicholas Wourms wrote: | |cgf wrote: | | |I'd like to explore new methods for getting packages into the |distribution, however. | |Possibly we need a gdb packages steering committee which decides on |these things. It could have rules like a package needs a simple |majority vote to be a candidate for inclusion. I'd envision seven |people on the committee. I have names in mind but the only two |definites are really Corinna and me, both of whom would also have veto |power. | |I'd also like to see a formal justification for why a package should be |included, remembering that we have a software web page at cygwin.com |which can be used to advertise packages that aren't quite up to snuff |for the cygwin release. I think we have accepted a couple of packages here |which really only deserve to be advertised on the web site. | |I'd really like to object to this SC idea, as most of us *have* |exercised restraint while a select few have not. Why should the |responsible maintainers be punished for someone's binge ITP'ing? I |think we should keep it the way it is, perhaps with a little more of you |laying the smack-down on anyone who is abusing it. I would respect a |veto from you, Corinna, or Chuck, but the voting should still be left to |the existing maintainers. After seeing what a steering committee has |done to gcc, I'd be very hesitant to subject Cygwin to one. | | | I guess we have differing views on how the steering committee affected | gcc but this is really very different from the gcc (or gdb) steering | committee. In general, I think they do a good job. | | However, just because I used a similar term to describe this doesn't | mean that it will be exactly like gcc's steering committee. | | I'm coming to feel that their should be a higher bar for package entry | into the release and don't think that any old package maintainer should | get an equal vote in the process. Why not make the vote proportional to the number of packages the maintainer maintains? I agree any ol' maintainer should not have as many votes as, say, you, but an SC might make things a bit too massive.. |Here's one idea to limit the binge ITP's: |No more than 1 ITP per month unless approved by either you or Corinna. | I can't speak for Corinna, but I would rather *not* have to be the bad | guy or a single (double?) point of contact. I would rather have more | community involvement. I'm already drowning in being the focal point | for most cygwin bugs with help from only two other developers. I don't | want to invent new things for me or Corinna to do, especially when there | is no requirement for in-depth cygwin knowledge. In that case, why not make the SC, but just five the SC members veto right whereas all package maintainers would still have the right to vote? In that case, you and Corinna would be permanent members of the SC and the package maintainers could nominate the five other members (two nominees per maintainer). The five members that get the most nominations become the members. If there's a tie, we vote. | Setting up a council or committee to approve or disprove apps means | that the load is shared and there theoretically a consistent way for | packages to be included. Yes, but it also takes away community involvement, concentrating it on a few elected members. long-winded_idea Let me elaborate my idea a bit: the SC would consist of seven members, all package maintainers and/or cygwin (or cygwin-setup) developers. Two members - cgf and Corinna - have a permanent seat on the SC. The other five members have a six-month (or perhaps 12-month) term renewable ad infinitum. All package maintainers get to vote on ITPs. The number of votes they carry is equal to the number of packages they maintain. Package admission requires at least 50% of the total votes (i.e. if there are 100 packages in the distro, 50 votes are required for a new packages to be admitted, but those 50 votes could come from only three people). To avoid one person getting a decisive positive vote, the 50% of votes must come from at least three different package maintainers. The SC members all get a veto right and may prioritize certain packages - - i.e. they may emit an ITP request (this would be a nice addition to the Cygwin distro - maintainer wanted). People that are not in the SC don't have the right to emit ITP requests. An ITP that is a response to an ITP request is exempt of voting. This gives the SC members positive power as well as the negative (veto) power they already have. It is up to the SC members to discuss ITP requests amongst themselves (on a dedicated cygwin-sc list, perhaps?) The SC members will also have the power to ban a package from the distro when it is already in the distro - either because the maintainer is MIA, the package has no real business being in the distro, or any other reason that is justifiable. Again, this
Re: [RFC] Would there be a need for a java-wrappers package?
Hello Igor, Personally, I'd much prefer a Free alternative to Java under Cygwin to a wrapper for Cygwin around Java. That notwithstanding, I think it is a good idea to have access to Java from Cygwin, so if you think it is a better idea to make wrapper scripts as opposed to ITPing a free Java implementation, by all means - you'll have my vote in either case :) rlc Igor Pechtchanski wrote: Hi, all, I would like to hear opinions on how useful a java-wrappers package would be. The package will contain a few shell scripts that allow users to invoke the regular Java SDK tools (java, javac, javadoc) from Cygwin, making them look like their Unix counterparts (i.e., POSIX filenames). The scripts would be updated versions of those posted in http://cygwin.com/ml/cygwin/2003-01/msg00174.html. There are a few reasons why I have misgivings about this. First off, some tools (notably Ant and Tomcat) recognize Cygwin and do something specific to Cygwin anyway, which will probably (most likely) get screwed up if the java they find looks like a Unix version (this did happen to me with Ant and Cygwin-native jikes). Secondly, the tools will certainly not be foolproof (although I'll try my best to make them as robust and autonomous as possible). Thirdly, java versioning may become a problem. Besides which, there's a procedural stumbling block in that all of my packages so far have been binary packages, and I'm not too sure exactly how to release a no-source one. For most of the above reasons, this is not an ITP yet. FWIW, I'm also planning to package jikes (which compiles OOTB) at some point soon, but I'd like to first work out, among others, the Ant bug mentioned above. Thanks for your (eventual) input, Igor
Re: [ITP] unrtf-0.19.0 - New package for review
Jari Aalto+mail.linux wrote: UnRTF is a moderately complicated converter from RTF to other formats, including HTML, LaTeX, text, and PostScript. Converting to HTML, it supports tables, fonts, colors, embedded images, hyperlinks, paragraph alignment among other things a) wget --non-verbose \ http://tierra.dyndns.org:81/cygwin/unrtf/setup.hint \ http://tierra.dyndns.org:81/cygwin/unrtf/unrtf-0.19.0-1-src.tar.bz2 \ http://tierra.dyndns.org:81/cygwin/unrtf/unrtf-0.19.0-1.tar.bz2 b) or use this: mkdir unrtf ; cd unrtf wget -q -O - http://tierra.dyndns.org:81/cygwin/unrtf/get.sh | sh Jari This has my vote. rlc NB: moved to Canada, catching up on my mail - month is about to start :)
Re: [ITP] catdoc-0.93.3 - New package
Jari Aalto+mail.linux wrote: Extract text from MS-Word files, trying to preserve as many special printable characters as possible. Catdoc doesn't attempt to analyze Word file formatting, it just extracts readable text. Known to support up to Word-97 format. http://freshmeat.net/projects/catdoc/ a) wget --non-verbose \ http://tierra.dyndns.org:81/cygwin/catdoc/catdoc-0.93.3-1-src.tar.bz2 \ http://tierra.dyndns.org:81/cygwin/catdoc/catdoc-0.93.3-1.tar.bz2 \ http://tierra.dyndns.org:81/cygwin/catdoc/setup.hint b) or use this mkdir catdoc ; cd catdoc wget -q -O - http://tierra.dyndns.org:81/cygwin/catdoc/get.sh | sh Jari This has my vote
Re: [ITP] git-4.3.20 GNU Interactive tools - new package
Jari Aalto+mail.linux wrote: git - Tools for simple, daily file and system management tasks A set of interactive tools that includes an extensible file system browser, an ASCII/hex file viewer, a process viewer/killer, and other related utilities and shell scripts. It increases the speed and ease of daily tasks like moving files and directories, invoking editors, compressing and uncompressing files, creating and expanding archives, compiling programs, sending mail, etc. It has colors if the standard ANSI color sequences are supported, and is user-friendly. http://www.gnu.org/directory/git.html a) wget --non-verbose \ http://tierra.dyndns.org:81/cygwin/git/git-4.3.20-1-src.tar.bz2 \ http://tierra.dyndns.org:81/cygwin/git/git-4.3.20-1.tar.bz2 \ http://tierra.dyndns.org:81/cygwin/git/setup.hint b) Or use this mkdir git ; cd git wget -q -O - http://tierra.dyndns.org:81/cygwin/git/get.sh | sh Jari +1 vote rlc
Re: coreutils maintainer needed
Christopher Faylor wrote: I think our textutils/nascent coreutils maintainer is again MIA. Can I get a volunteer to support the coreutils package? coreutils will supercede fileutils and textutils. cgf If no-one else steps up, I'll be happy to step in :) I am currently setting up a new Cygwin-enabled Windows environment. As soon as I have it set up, I'll take a close look at coreutils. I also have a few ITPs pipelined, as well as the british Bash bug and perhaps a patch to Cygwin itself - but hey, the month is about to start ;) rlc
Re: coreutils maintainer needed
Christopher Faylor wrote: I think our textutils/nascent coreutils maintainer is again MIA. Can I get a volunteer to support the coreutils package? coreutils will supercede fileutils and textutils. cgf If no-one else steps up, I'll be happy to step in :) I am currently setting up a new Cygwin-enabled Windows environment. As soon as I have it set up, I'll take a close look at coreutils. I also have a few ITPs pipelined, as well as the british Bash bug and perhaps a patch to Cygwin itself - but hey, the month is about to start ;) rlc -- 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: [jjohnstn: initial version of iconv support checked in]
On Thu, Jan 29, 2004 at 09:29:46AM -0500, Nicholas Wourms wrote: rlc wrote: Please don't: we already have a perfectly good iconv implementation in the distribution and there's no law against providing iconv as a separate library from the kernel/libc/whatnot. Of course it isn't against the law, but the fact is that most modern, non-microsoft, libc's provide it. Not all apps are GNU and some require a good deal of retooling to get them to recognize our libiconv. I understand that not all software is GNU - I work on non-GNU software most of the time. As for the re-tooling of apps to recognise libiconv - most of those apps will probably need re-tooling for other iconv implementations as well. AFAIC, the mere fact that porting an application may need a wee bit of work for an iconv implementation (one which, currently, is not Cygwin-specific in any way) doesn't mean all that much to me: the same iconv implementation is available on many platforms and, as such, the effort of porting to Cygwin will simply help porting to those platforms as well.. You also might want to consider the interests of our current libiconv maintainer, who also happens to maintain quite a few other core packages. I'm almost certain that he'd welcome not having to prepare and release new libiconv versions. I don't know that - haven't heard from him. What I also haven't heard is that including an iconv implementation in Cygwin would automatically mean no longer distributing GNU iconv, but that's another story. Also, you forget the fact that some of the binaries packaged in the Cygwin dll package rely on the external libiconv. IMHO, applications which are part of that core package really ought not to rely on a library external to those provided by cygwin/w32api/newlib/libiberty. Ehm.. why? Finally, it might be something desired by those looking to actually pay $$$ to license the Cygwin dll for use in non-GPL projects. AFAIK (but correct me if I'm wrong) the commercially licensed Cygwin is not necessarilly the same as the Net release - in which case iconv could easily be built into that one. Otherwise, IIUC, the iconv implementation that could be built into Newlib can be built as a separate library, which would be available under the same licensing terms as Newlib itself (i.e. BSD-like license). That basically means there's an alternative to GNU iconv ported to Cygwin already.. By far most applications don't care too much about transcoding, so most applications would simply have to carry around some extra luggage if it were built into the Cygwin DLL. Stop spreading FUD, that last part isn't true at all. There is no extra baggage, if anything, application sizes might be reduced by a minuscule amount. This is assuming one less external library would make for a slightly smaller PE header. However, since it is: A) impossible, by design, to statically link with Cygwin's libc and... B) impossible, by design, for ld to re-export symbols found in libc[1] this concern really is a moot one. It is definitely not my intention to spread FUD, but you're probably right: an iconv implementation hardly qualifies as code bloat. That, and I wonder how libiconv would interact with this.. but as I haven't given that any thought at all (only one neuron assigned to the task for the next two seconds or so) I wouldn't be willing to make any guesses about that. Simple, this replaces libiconv. The libiconv dev package would be obsoleted, replaced with an empty one, however we would retain current libiconv runtime libs for compatibility. This won't affect applications built against the old libiconv since the old libiconv data files aren't clobbered by newlib's iconv. Shared static libraries, however, would need to be rebuilt since libiconv uses different symbols from the libc iconv (it uses #define's in iconv.h to alias the expected symbols, such as iconv_open, to the libiconv versions. There's a point I definitely wouldn't be happy with: I like GNU's iconv and don't know Newlib's new iconv, so anything I wrote that uses iconv would need new QA. Personally, I would much prefer peaceful cohabitation of the two iconvs for as far as that is possible - and AFAIK, that should be possible because of the #defines in iconv. Just my $0.02 (canadian - which is where I will be going in two wheels and three spokes [1]) Which is about $0.0125 US... As I said before, I think we should take a wait and see approach. There's no rush or reason to make a decision now, since it is disabled by default. Let some people try it out on their own and report back with their findings. We can always revisit this at a later time, once the newlib iconv support is more mature. Yes: we can always revisit this later - I was just voicing my first concern about a new, possibly incompatible, iconv implementation. I have no intention to spread any FUD and I am confident that nothing important will be broken
Re: [ITP] boxes-2000.0401 - Draw character boxes
this has my vote! rlc On Thu, Jan 29, 2004 at 06:43:25PM +0200, Jari Aalto+mail.linux wrote: See http://boxes.thomasjensen.com/ Packages available for review: http://tierra.dyndns.org:81/cygwin/boxes/boxes-2000.0401-1-src.tar.bz2 http://tierra.dyndns.org:81/cygwin/boxes/boxes-2000.0401-1.tar.bz2 http://tierra.dyndns.org:81/cygwin/boxes/setup.hint To download: wget -q -O - http://tierra.dyndns.org:81/cygwin/boxes/get.sh | sh Content: usr usr/share usr/share/doc usr/share/doc/boxes-2000.0401 usr/share/doc/boxes-2000.0401/COPYING usr/share/doc/boxes-2000.0401/README usr/share/doc/boxes-2000.0401/README~ usr/share/doc/boxes-2000.0401/README.Win32.txt usr/share/doc/Cygwin usr/share/doc/Cygwin/boxes-2000.0401.README usr/share/man usr/share/man/man1 usr/share/man/man1/boxes.1 usr/bin usr/bin/boxes.exe Jari -- http://tiny-tools.sourceforge.net/ Swatch @time http://www.mir.com.my/iTime/itime.htm http://www.ryanthiessen.com/swatch/resources.htm Use Licenses! http://www.linuxjournal.com/article.php?sid=6225 Which Licence? http://www.linuxjournal.com/article.php?sid=4825 OSI Licences http://www.opensource.org/licenses/ -- In order to discover who you are, first learn who everybody else is; you're what's left.
Re: [ITP] aspell-de-0.50.2 - German dictionary files for aspell
I vote for this :) (and I'll take it out of my ITPs waiting list). rlc On Fri, Jan 30, 2004 at 02:12:48PM +0100, Dr. Volker Zell wrote: Hi I would like to contribute and maintain the aspell-de package: * http://aspell.net/ (Homepage) * http://ftp.gnu.org/gnu/aspell/dict/ (Download location) ! downloadsize 5 MB ! Ciao Volker -- Here is the setup.hint file: sdesc: German dictionary files for aspell ldesc: German dictionary files for aspell category: Text requires: cygwin aspell cut here #!/bin/bash mkdir aspell-de cd aspell-de wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-de/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-de/aspell-de-0.50.2-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-de/aspell-de-0.50.2-1.tar.bz2 cut here -- Good leaders being scarce, following yourself is allowed.
Re: [ITP] aspell-pl-0.50.2: Polish dictionary files for aspell
On Sat, Jan 31, 2004 at 04:19:24AM +1100, Gareth Pearce wrote: Aspell-de +1 as well. I don't think I officially ITPed this yet, but it's in the pipeline unless someone beats me (has beaten me?) to it.. rlc NB: -fr and -nl are in the pipeline before -de, though..)
Curious categories for Doxygen
I was just wondering why Doxygen is not in the Doc category, while Docbook (and even expat) is.. Just wondering :) rlc -- Pascal Users: The Pascal system will be replaced next Tuesday by Cobol. Please modify your programs accordingly.
Re: [ITP] aspell-pl-0.50.2: Polish dictionary files for aspell
This has my vote :) (I don't speak polish, but my wife has Polish origins) rlc On Fri, Jan 30, 2004 at 02:13:40PM +0100, Dr. Volker Zell wrote: Hi I would like to contribute and maintain the aspell-pl package: * http://aspell.net/ (Homepage) * http://ftp.gnu.org/gnu/aspell/dict/ (Download location) ! Download size 9 MB Ciao Volker -- Here is the setup.hint file: sdesc: Polish dictionary files for aspell ldesc: Polish dictionary files for aspell category: Text requires: cygwin aspell cut here #!/bin/bash mkdir aspell-pl cd aspell-pl wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-pl/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-pl/aspell-pl-0.50-2-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/aspell-pl/aspell-pl-0.50-2-1.tar.bz2 cut here -- Generic Fortune.
Re: [jjohnstn: initial version of iconv support checked in]
Please don't: we already have a perfectly good iconv implementation in the distribution and there's no law against providing iconv as a separate library from the kernel/libc/whatnot. By far most applications don't care too much about transcoding, so most applications would simply have to carry around some extra luggage if it were built into the Cygwin DLL. That, and I wonder how libiconv would interact with this.. but as I haven't given that any thought at all (only one neuron assigned to the task for the next two seconds or so) I wouldn't be willing to make any guesses about that. Just my $0.02 (canadian - which is where I will be going in two wheels and three spokes [1]) rlc 1: OK: wheel was just a type-o, but I thought it was funny... Anyways, the month will start Feb 17th and if finances permit might be extended a bit.. On Wed, Jan 28, 2004 at 09:56:44PM +0100, Christopher Faylor wrote: The below is just an FYI. This means that the iconv stuff could be built into the DLL, bloating the dll even more I suppose. Is this something that we want to do? I vote no, but I thought I should mention this to the collective wisdom of cygwin-apps since it essentially boils down to a package issue. cgf - Forwarded message from Jeff Johnston - From: Jeff Johnston To: newlib Subject: initial version of iconv support checked in Date: Fri, 23 Jan 2004 16:56:09 -0500 This is just to note that the initial version of Artem Bityuckiy's iconv code has been checked in. It can be activated using the configuration option: --enable-newlib-iconv Builtin iconv converters can be selected using the configuration option: --enable-newlib-builtin-converters This iconv code cannot currently be used with i686-pc-linux-gnu which has its own iconv support. Thanks to Artem for this major piece of work. -- Jeff J. - End forwarded message - -- Pollyanna's Educational Constant: The hyperactive child is never absent.
Re: Pending patches for generic build script
On Tue, Jan 27, 2004 at 12:02:50PM -0500, Igor Pechtchanski wrote: I was going to reply to Chuck's original message, but here goes: On Tue, 27 Jan 2004, Ronald Landheer-Cieslak wrote: On Sun, Jan 25, 2004 at 01:38:50PM -0500, Charles Wilson wrote: Here are the patches I have/had on my 'pending' list for the generic-build-script. Thanks for (permanently or even just temporarily) handling these maintainance duties, Igor... Some of these messages spawned threads and updated patches; be sure to read all replies. Alan Miles: Diff for generic readme and generic-build script http://cygwin.com/ml/cygwin/2003-11/msg00700.html Alan Miles: Diff for generic readme and generic-build script to automatically generate pkg data and file listings http://www.cygwin.com/ml/cygwin/2003-11/msg01067.html These two are the same... They aren't, but the final patches in all of the resulting threads are. That's what I meant - sorry for the confusion.. Alan Miles: Patch for generic readme and generic-build script to automatically generate pkg data and file listings http://cygwin.com/ml/cygwin-apps/2004-01/msg00042.html AFAICS, this one is the same as well.. I've been looking at the above patch (all 3 copies). Harold Hunt: Patch to generic-build-script for listing package files http://www.cygwin.com/ml/cygwin-apps/2003-10/msg00351.html AFAICT, the patch above includes this functionality (but this is a nice alternate method, perhaps... This one's already in. The ChangeLog could use updating, though -- it only reflects two early changes. I'll take care of that. OK. Lapo Luchini: patch to generic-build-script (updated to cvs 1.4) http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00323.html This one looks interesting though very, well.., paranoid ;) I agree with the spaces at ends of lines sentiment. I'm working on a cleanup pass (formatting and spacing) now. Hmm.. I guess you both are a bit more paranoid than I am :) Lapo Luchini: patch to generic-build-script http://www.cygwin.com/ml/cygwin-apps/2003-06/msg00273.html Look pretty much like the previous one.. Yes, it does. I'll have a really close look at the two non-duplicates. rlc Ronald, if you could please split this last patch into the whitespace/formatting part and the contributions part, it would make it much easier to commit. I'll keep looking at the first one for now (after I'm done with the whitespace changes). Due to my lack of paranoia, that's more or less what I'm doing: I was planning to simply get rid of the paranoid stuff and split the patch into functional chunks (tarname diffs as one chunk, etc.). The first patch looks nice, but I haven't gotten around to testing it thouroughly yet. I'll do that tomorow morning (note the timezone difference: that would be at about midnight chez toi). Again, the month hasn't started yet - I'm working during coffee and lunch breaks. rlc
Re: Keypress anomaly: maybe locality specific
Just an update: I can reproduce the error locally and will try to debug it. Don't expect a fix too soon, though - the month hasn't started yet. rlc On Mon, Jan 26, 2004 at 08:10:10PM +0100, Ronald Landheer-Cieslak wrote: OK, from the responses I got (and the code I looked at) I gather that my initial hunch has a good chance of being correct: this is not a Cygwin-specific problem and is likely to be located in the readline library. I'll be wrapping up an experimental version of Bash for the interested to try out which will not use readline, but will use curses instead. If that works, I'll conclude that my hunch is correct and will try to debug readline.. That'll be tomorow, though.. rlc -- Cleanliness is next to impossible. Jail: Just Another Interpreted Language Just: Jail Uses Silly Terms Join the discussion on the definition of this language at [EMAIL PROTECTED] http://jail-ust.sourceforge.net (send mail to [EMAIL PROTECTED]) -- 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/ -- You can't cheat the phone company. -- 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: sftp + cygwin
On Fri, Jan 23, 2004 at 10:44:08AM -0800, [EMAIL PROTECTED] wrote: How can I sftp defauly folder when I am using cygwin. It points to c: drive right now. Please read the text at http://cygwin.com/problems.html and re-phrase your question. Thanks, rlc -- Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record. -- 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: Keypress anomaly: maybe locality specific
On Mon, Jan 26, 2004 at 01:14:07PM -, [EMAIL PROTECTED] wrote: Windows XP. The anomaly happens in Cygwin 1.5.6 and 1.5.5 and maybe earlier still, but I have no way of confirming this ... it's a bit parochial (may be UK specific, I think) but I'd like to describe it here as, I hope, an easily identifiable and curable anomaly. This comes to you from the UK. If I set keyboard= language= everything else= US within Windows, and operate from the sparsest possible bash console within Cygwin, everything works fine. The symbols I get on screen don't quite match what is painted on the keys I pressed, but that's as expected, because my keyboard is a UK one. Usually it's one-one. In a small number of cases one ends up playing a kind of connected game of chase, running through @ and and also \ and | and ~ before learning what gives what. In particular Shift-3 gives the hash symbol #, even though what's painted on the key is a £ sign (UK pound). I have found no way of actually getting a £ sign, but nor can I get a whole load of other symbols, currency and all sorts, so this is no surprise. Now use the Control Panel to change at the Windows level to keyboard= language= everything else= UK (my standard settings, in fact). Now there's an exact match between what's painted on the keys and what appears on screen for all of and @ and ... and now Shift-3 gives £, as painted on the key. It is what I get in Word, at the XP Command Prompt, in Notepad and all the rest. I even get it in nano-within-Cygwin and vim-within-Cygwin. But, oddly, at the bash command line in Cygwin I get not a GB pound sign £; and not even the hash sign #; but actually a two key combination # + Enter, so that one gets taken to a new, empty, command line. The hash sign alone is printed. If I type $ 789Shift-3 (don't press Enter) what I get on screen is $ #789 $ so the hash is printed at the start of the line AND an Enter is assumed. There is probably a level (e.g. printers) at which an emailed query about weird behaviour would quite rightly get the response It's your printer, you're on your own. I appreciate the somewhat locality-specific nature of this query, but have I explained it sufficiently to suggest that it shouldn't be happening, even in a minority situation, and maybe for cause and cure to be evident to somebody who can implement that cure? Hmm.. another case of weirdness staring me in the face.. Off the top of my hat (WAG-style) I'd say this looks like a readline problem.. If you're willing to bare with me on some now-try-this debugging, I might be able to help you out.. Unfortunately, I do not have a UK keyboard :( In any case, the first thing needed would be a cygcheck output (attached) as described in http://cygwin.com/problems.html. After that, I can either provide you with some now try this instructions (involving compiling Bash) or provide you with some specially-compiler Bash versions to see whether they behave correctly. First, though, the cygcheck output would be nice, and it would be nice to know if there are any other programs than Bash that have this problem..? rlc -- Just remember, wherever you go, there you are. -- Buckaroo Bonzai -- 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: Keypress anomaly: maybe locality specific
OK, from the responses I got (and the code I looked at) I gather that my initial hunch has a good chance of being correct: this is not a Cygwin-specific problem and is likely to be located in the readline library. I'll be wrapping up an experimental version of Bash for the interested to try out which will not use readline, but will use curses instead. If that works, I'll conclude that my hunch is correct and will try to debug readline.. That'll be tomorow, though.. rlc -- Cleanliness is next to impossible. Jail: Just Another Interpreted Language Just: Jail Uses Silly Terms Join the discussion on the definition of this language at [EMAIL PROTECTED] http://jail-ust.sourceforge.net (send mail to [EMAIL PROTECTED]) -- 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: generic-build-script maintainership (WAS Re: non-widget child DropSiteManager error)
On Wed, Jan 21, 2004 at 02:58:01PM -0500, Igor Pechtchanski wrote: On Wed, 21 Jan 2004, Christopher Faylor wrote: On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: Does http://cygwin.com/ml/cygwin/2004-01/msg00409.html count as (temporarily) passing the baton? Yes. What are you waiting for? :-) cgf I don't have a month worth of developers time. :-) I do plan to try to at least get my patches (which I already understand) into the generic-build-script at some point in the near future. Time permitting, others may follow. Igor I *do* have a month worth of developers time on my hands - starting in three weeks. If the patches can wait for another three weeks, I'll be happy to take on maintainership of the generic build script. Sorry for the late reply, BTW: the month hasn't started yet ;) rlc -- Do not do unto others as you would they should do unto you. Their tastes may not be the same. -- George Bernard Shaw
Re: generic-build-script maintainership (WAS Re: non-widget child DropSiteManager error)
My previous response notwithstanding, if you (Igor) do intend to take over maintainership of the generic build script, please feel free to go ahead and do it - I'll spend the time on something else (I've received a request to ITP libsegv, which currently fails two of four testsuite tests, and will look into it; I've also received a request to add a couple of POSIX system calls to Cygwin (for which I'd have to print, sign and send the copyright waiver, which is on my TODO list for next week) and I have a draft design for pluggable fhandlers, based on what fhandlers were like before cgf changed them for 1.5.6.. (I haven't checked out the current version from CVS yet to adapt my design). I really do intend to spend a month's time on this project (including the update of the documentation) and I also do intend to make sure I can continue working on Cygwin-related work when I start looking for a paid job again.. rlc On Wed, Jan 21, 2004 at 02:58:01PM -0500, Igor Pechtchanski wrote: On Wed, 21 Jan 2004, Christopher Faylor wrote: On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: Does http://cygwin.com/ml/cygwin/2004-01/msg00409.html count as (temporarily) passing the baton? Yes. What are you waiting for? :-) cgf I don't have a month worth of developers time. :-) I do plan to try to at least get my patches (which I already understand) into the generic-build-script at some point in the near future. Time permitting, others may follow. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Dental health is next to mental health.
Re: generic-build-script maintainership (WAS Re: non-widget child DropSiteManager error)
On Fri, Jan 23, 2004 at 08:52:42AM -0500, Igor Pechtchanski wrote: I hope what I said below didn't come out as I will take over maintainership. Not really: I think the ``I don't have a month worth of developers time. :-)'' was pretty clear that you didn't intend to take over maintainership :) Just wanted to make sure, though :) I may be able to commit a few patches (since I have access already), but I doubt I'll have much time for extensive testing or reviewing of others' patches. It would make me much more comfortable if someone else served as a buffer between me and the raw CVS, and at least reviewed and approved my (and others') patches. As the generic build script is pretty wide-spread I definitely understand that :) If you wish, we could do it the way Pierre, Thomas, and others with commit access deal with the winsup repository: they can commit, but their patches have to be approved by either CGF or Corinna first. If you want to serve as an approver (maintainer) and double-check my decisions, I can take care of committing the patches. Good idea - I'll be happy to check the different patches and it doesn't require me to have commit access :) Once again, though: the month of developer's time doesn't start for another three weeks. Before that, I won't be able to do much of anything as far as Cygwin is concerned.. [snipped previous discussion] rlc
Re: MS offers Services For Unix free of charge
On Fri, Jan 16, 2004 at 11:29:53AM +0100, S. L. wrote: [...] It would be rather interesting to add nfs to cygwin. We could develop filesystem plug-ins which could be generalized for stuff like NFS, EXTFS, etc. Didn't someone say they had a free month? Perfect project. :-) Actually, I'd already been thinking about it - I think I'll be sending a copyright assignment shortly.. rlc [...] YOU'RE THE MAN! Whoa there - easy now! It ain't done yet :) I've been *thinking* about it - not a single line of code has been typed yet and my CVS checkout of Cygwin's repo is way out of date.. But I'm still thinking about it and ideas of how it could be done are using up my brain's CPU cycles, so I might start typing something any day now :) rlc -- 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: MS offers Services For Unix free of charge
On Wed, Jan 14, 2004 at 04:36:17PM -0500, Christopher Faylor wrote: On Wed, Jan 14, 2004 at 04:26:03PM -0500, Robb, Sam wrote: But beyond curiosity, there's not many reasons to install and use both, at least concurrently. Cygwin and SFU both address the same needs and Cygwin covers a wider range of tools. We'll see what happens though. One thing that Cygwin does lack, and SFU has, is an NFS client :-/ I know that alone will probably entice me into taking a look at SFU. It would be rather interesting to add nfs to cygwin. We could develop filesystem plug-ins which could be generalized for stuff like NFS, EXTFS, etc. Didn't someone say they had a free month? Perfect project. :-) Actually, I'd already been thinking about it - I think I'll be sending a copyright assignment shortly.. rlc -- Immortality consists largely of boredom. -- Zefrem Cochrane, Metamorphosis, stardate 3219.8 -- 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: A month worth of developers time available for cygwin.
I don't have commit access, but I will have the time in four weeks :) If you've been dutifully archiving the patches, I'll be happy to examine them. I wouldn't be at all surprised if people have in deed been waiting for you to patch the generic build script: AFAIKnew, it's your script, right? :) rlc On Thu, Jan 15, 2004 at 01:28:02AM -0500, Charles Wilson wrote: Igor Pechtchanski wrote: Note that there are a couple of patches to the generic build script floating around in the cygwin-apps archives. Also, it might pay to look at the sources of a bunch of Cygwin packages that use the generic build script, and compare/extract the good bits/parameterize the differences. I'm sure people (read: package maintainers) will appreciate a new release of the generic build script, and it will also make it easier to eventually switch to an RPM/dpkg-like model. Request: can somebody else with commit access please look into this (I have a hunch that folks are waiting for _me_ to do this...) I've been dutifully archiving the various posted patches but I just can't find any extra time to sift out the wheat from the chaff. Job/Personal/RealLife is intruding heavily just now... -- Chuck -- 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/ -- Traffic jam on the Information Superhighway. -- 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: A month worth of developers time available for cygwin.
I've gotten my local Cygwin installation up to speed for this (openjade et al.) but I'll probably be working on my Gentoo box at home (seeing as I only have one Windows at my disposal at home, which does have Cygwin but which I hardly ever use, I'll do as much as possible on my normal development box..) I'll try to get things working so I can run `make' properly and will report back when I've either gotten things going or have run into some really blocking problem.. rlc On Tue, Jan 13, 2004 at 10:22:10PM -0600, Joshua Daniel Franklin wrote: On Tue, Jan 13, 2004 at 03:46:12PM +0100, Ronald Landheer-Cieslak wrote: I'd be happy to help out with the documentation. As for the documentation build system: what do I need? As far as the Cygwin distribution goes, you need to have all the normal build tools (gcc,make,etc) and a couple you might not-- libxml2 and rpm. Before the letters R P M scare people, let me digress. Up until now the Cygwin documentation has been built either on Linux or with custom Cygwin packages. (Note to you and to future list readers, this hopefully will change very soon--maybe as soon as we get Nicholas' openjade patches and can get it and the various DTD and stylesheets in the distribution.) The problem with installing custom packages is that you can get them confused with real ones and create a dependency mess as you attempt to move from custom to official packages. Right now on Cygwin all we have is custom packages for SGML docbook (which is what the Users' Guide and API Reference are written in). Nicholas mentioned that he'd been using Red Hat's SRPMs, so I thought I'd try that for the transitional phase. Just to be clear here, RPM is not becoming an official Cygwin installation method, and most RPMs you find on the Web will *NOT* work in Cygwin. That said, I've put up my hacked-together RPMs at: http://ns1.iocc.com/~joshua/cygwin/RPMS/ Note that RPM has many features such as dependency management that I've deliberately ripped out of these, so don't get too excited. Note also that there is an openjade-1.3.1-1.tar.bz2 there. This was packaged about two years ago before there was trouble building openjade, so it's quite old, but works for our purposes: --snip--- # 1. Get the files cd /tmp wget -m -np -nH --cut-dirs=3 http://ns1.iocc.com/~joshua/cygwin/RPMS/ # 2. Never do this again--it's a very bad idea cd / tar jxvf /tmp/openjade-1.3-1.1.tar.bz2 # 3. Install the hacked-together dependencies rpms rpm -Uhv /tmp/*rpm # 4. Install the actual docbook packages rpm -Uhv /tmp/docbook/*rpm # 5. Remove everything you've installed with rpm with one easy step #onces we've got Cygwin packages together--no mess! rpm -e $(rpm -qa) --snip--- Once you've got that, all you should need to do it type make in the winsup/doc folder of your Cygwin build tree. There are a couple of other things you might want to do: -comment out (with -- before and after) the DTDDECL statement in /usr/share/sgml/docbook/dsssl-stylesheets/catalog This version of jade just hates the DTDDECL and complains loudly. -Change /usr/bin/db2html's shebang to #!/bin/bash since it uses bash-specific artithmetic syntax. -Remove the cygwin-ug/cygwin-ug.html and cygwin-api-int/cygwin-api-int.html build targets from winsup/doc/Makefile.in or just wait a week--see http://www.cygwin.com/ml/cygwin-patches/2004-q1/msg4.html Hope this helps you get going, and let me know if you have any other questions. You're welcome to work on most anything, though I think having an improved API reference including real compilable examples would be great. The API is documented in SGML files in winsup/cygwin/ and a few source files (pinfo.cc). Grep for funcsynopsis. Anyone else chime in with other todos? -- 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/ -- Are [Linux users] lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software? (By Matt Welsh) -- 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: A month worth of developers time available for cygwin.
On Mon, Jan 12, 2004 at 08:13:03PM -0600, Joshua Daniel Franklin wrote: On Mon, Jan 12, 2004 at 10:39:08AM -0500, Christopher Faylor wrote: On Mon, Jan 12, 2004 at 03:39:03PM +0100, Ronald Landheer-Cieslak wrote: This message is intended mostly for the Cygwin core developers. I will be quitting my job mid februari (the 13th) and moving to Canada where I won't start searching for a job until at least three weeks after our arrival (I'll be looking after my daughter in stead). As I don't expect taking care of my daughter will take all of my time, I have some time left on my hands. I've been using Cygwin for quite a while now and would like to use the time I'll have on my hands to do something useful for Cygwin. Since the last time I wanted to offer my time (which finally didn't work out mostly because my employer didn't want to sign the necessary paperwork) I've gotten the rust off my C++ skills (and haven't let my other development skills rust either). So if you think the project can use a developer for three to four weeks, I'll be happy to help out. Just point me to something you would like me to do :) It's very nice of you to offer. I think the biggest thing we could use help on is documentation. Going over the documents, removing obsolete bits, clarifying obscure stuff, etc. I don't want to step on Joshua's toes here so maybe he'll correct me if I'm wrong, but I think the docs could use some work. Chris is absolutely right. There are a lot of things that I have not been able to touch, for example the API Reference needs updating and examples. Additionally it's a good idea to have someone else read over things since something that makes sense to me might be nonsense to everyone else. If this sounds like something you'd be interested in doing, I'd be happy to help you get a working documentation-build system and answer any questions about it. I know documentation isn't as fun as implementing features, but it definitely helps users. I'd be happy to help out with the documentation. As for the documentation build system: what do I need? rlc -- 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: A month worth of developers time available for cygwin.
The most recent thread I've found on the subject dates back from 2001 and starts at http://sources.redhat.com/ml/cygwin-apps/2001-03/msg00170.html. I'm reading the thread now (well.. during coffee breaks - I'm not off the job quite yet). If this is not the thread I should be looking at, please feel free to point me in the right direction.. rlc On Mon, Jan 12, 2004 at 07:03:04PM -0500, Charles Wilson wrote: Christopher Faylor wrote: Otherwise, I can't think of a specific thing to point at and say Work on that. Maybe serial support? Perhaps Robert has some open issues in setup? (wishlist: rpm/dpkg support in setup -- this is a very difficult task; search ml archives for an outline of the synchonization issues...) -- Chuck -- 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/ -- Two brothers, Mort and Bill, like to sail. While Bill has a great deal of experience, he certainly isn't the rigger Mort is. -- 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: Pending Packages List, 2004-01-09
On Fri, Jan 09, 2004 at 05:00:01PM -, Daniel Reed wrote: Package: rxp 1.3.0-1 [2003-11-11] Package: elinks 0.9.0-2 [2003-12-26] Package: openldap 2.1.25-1 [2004-01-02] These have my vote. rlc
A month worth of developers time available for Cygwin.
This message is intended mostly for the Cygwin core developers. I will be quitting my job mid februari (the 13th) and moving to Canada where I won't start searching for a job until at least three weeks after our arrival (I'll be looking after my daughter in stead). As I don't expect taking care of my daughter will take all of my time, I have some time left on my hands. I've been using Cygwin for quite a while now and would like to use the time I'll have on my hands to do something useful for Cygwin. Since the last time I wanted to offer my time (which finally didn't work out mostly because my employer didn't want to sign the necessary paperwork) I've gotten the rust off my C++ skills (and haven't let my other development skills rust either). So if you think the project can use a developer for three to four weeks, I'll be happy to help out. Just point me to something you would like me to do :) rlc -- Your depth of comprehension may tend to make you lax in worldly ways. -- 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: ITP: help2man-1.33.1-1
I vote for this - this has my vote. rlc On Wed, Jan 07, 2004 at 04:50:11AM -0500, Yaakov Selkowitz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to contribute GNU help2man to the Cygwin net distribution. Due to a problem in the code for the NLS component (hacklocaledir.c), I built this package WITHOUT NLS, through a configure flag. If anyone can figure out how to get NLS working (see my response to Gerrit Haase a few minutes ago) please post to the list. This will become a build req for my proposed gtypist package, which is held up due to this dependency (and assumption that it's already installed on the system). I have used it for other things as well, such as making a man page for tar. The help2man package can be downloaded and installed through setup.exe at: http://mysite.verizon.net/yselkowitz/cygwin/ Or downloaded manually: wget \ http://mysite.verizon.net/yselkowitz/cygwin/release/help2man/help2man-1.33.1-1.tar.bz2 wget \ http://mysite.verizon.net/yselkowitz/cygwin/release/help2man/help2man-1.33.1-1-src.tar.bz2 wget \ http://mysite.verizon.net/yselkowitz/cygwin/release/help2man/setup.hint Md5sums: 0b184f0b82b060938e55c75e5e4caa89 *release/help2man/help2man-1.33.1-1-src.tar.bz2 0fe76695b9d368d72871dd0978e8024a *release/help2man/help2man-1.33.1-1.tar.bz2 a802307bea315fe00d8eddfb17f3a22f *release/help2man/setup.hint setup.hint: category: Devel requires: perl sdesc: Creates man pages from program output ldesc: Perl script that automatically creates man pages from the output from a program's --help and --version options. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) - WinPT 0.7.96 iD8DBQE/+9ZIpiWmPGlmQSMRAlxxAKDYTkFmyF0ytpQNFQJoHBg1g1DztACffE3h xQ4m0tewbfnwbyQ3Ck5b4XU= =wGGH -END PGP SIGNATURE- __ Thank you for using Netscape. -- YOW!! I'm in a very clever and adorable INSANE ASYLUM!!
[OT] profiting from info gathered by aaaspam@sourceware.org
Completely off-topic - I hope you don't mind - but with the recent increase of spam in my mailbox, I was wondering if there is any way to get the list of E-mail addresses blacklisted by [EMAIL PROTECTED], to check new E-mails against that list and dump them if they're in there.. rlc -- There are some things worth dying for. -- Kirk, Errand of Mercy, stardate 3201.7 -- 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: Pending Packages List, 2003-12-16
On Tue, Dec 16, 2003 at 05:00:01PM -, Daniel Reed wrote: Package: dhcp 3.0.1rc11-1 [2003-12-12] Package: ccrypt 1.6-1 [2003-12-14] These have my vote(s) - I vote for these :) rlc -- Go ahead... make my day. -- Dirty Harry
Update: pcre-4.5-1
I just noticed that a week-end of sleep is a Good Thing when it comes to writing mail. With the corrected subject line above, I hope it gets noticed ;) The latest canonical pcre version is available for Cygwin. MD5 sums and URLs below. (You can also point Setup to http://rlc.unsane.co.uk/, BTW, but notice that there is also non-canonical stuff on that server). e891737e53e5675f65eea6ba15d7d0ef *pcre-4.5-1-src.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1-src.tar.bz2 04754e6ba8866035ff8b99a9e37e8bcd *pcre-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1.tar.bz2 fe1e4a8b37f9ebc68c2e2bc9b4482349 *pcre-devel-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.5-1.tar.bz2 be168960d6edd3a913e3aabb9984b09d *pcre-doc-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.5-1.tar.bz2 211a9657aae65a15780aaa8247bad7ac *libpcre0-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/libpcre0-4.5-1.tar.bz2 prev: 4.4-2 please remove anything older than 4.4-2. Thanks, rlc
Re: new pcre packages ready for download
Announcement sent - thanks :) rlc On Fri, Dec 12, 2003 at 06:10:33PM -0500, Daniel Reed wrote: On 2003-12-12T15:19+0100, Ronald Landheer-Cieslak wrote: ) http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1-src.tar.bz2 ) http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1.tar.bz2 ) http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.5-1.tar.bz2 ) http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.5-1.tar.bz2 ) http://rlc.unsane.co.uk/release/pcre/libpcre0-4.5-1.tar.bz2 ... ) please remove anything older than 4.4-2. Done and done. Thanks for the update. -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ There are people who do things and people who take the credit, and the trick is to be in the first group; there is a lot less competition. -- Dwight Morrow, American Diplomat -- If a child annoys you, quiet him by brushing his hair. If this doesn't work, use the other side of the brush on the other end of the child.
[ANNOUNCEMENT] Updated: pcre-4.5-1
New News: = Version 4.5-1 of the PCRE packages is now available for download. This corresponds to the latest official PCRE release. The only changes applied to this version wrt the canonical version involve the build process. To update your installation: === Run the Setup utility from http://cygwin.com/setup.exe and pick up the proper packages. Problem reports: === Please send reports of any problems related to these packages to [EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a regular basis. Old News: The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. PCRE has its own native API, as well as a set of wrapper functions that correspond to the POSIX regular expression API. The PCRE library is free, even for building commercial software. have a look at http://www.pcre.org for details Port Notes: - version 4.5-1 - Update to canonical 4.5 - version 4.4-2 - Move the Cygwin-special README to the proper location - version 4.4-1 - Patches applied to 4.3-x were largely integrated into the canonical package. The rest of the patches (of course) still apply - version 4.3-4 - Make doc package FHS compliant - version 4.3-3 - Recompile against Cygwin-1.5.0 - version 4.3-2 - Added pcre-config script to pcre-devel package - version 4.3-1 - The same patches as applied to version 4.2-2 were applied to this version. - version 4.2-2 - A slight modification was made to the packaging script to kill a bug that had snuck into the tarballs - version 4.2-1 - The patch I made earlier, which got into the canonical PCRE, worked around using Libtool on Cygwin without there being any need to do so, as Gerrit P. Haase kindly pointed out. With his patch and one by Charles Wilson, the Cygwin build procedure is just like any *NIX - due thanks go to the both of them. - versions prior to 4.2-1 - Anything prior to 4.2-1 was maintained by Corinna Vinschen - any notes on those versions are available in the mail archives. -- Forgetfulness, n.: A gift of God bestowed upon debtors in compensation for their destitution of conscience. -- 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: [OT] RE: Third-party products that include cygwin
On Mon, Dec 15, 2003 at 12:22:47PM -0500, Christopher Faylor wrote: On Mon, Dec 15, 2003 at 11:39:25AM -0500, Igor Pechtchanski wrote: I feel your pain, but there seems to be a light at the end of the tunnel. I have Outlook Express 5 installed on my machine (though I don't use it), and I've poked around a bit. Try going to the Tools-Accounts menu from the main window, and adding a Mail account. Once you add it, select it and click on Properties. One of the options there is the Reply address (which looks like what you want). HTH anyone who is forced to use Outaluck^H^H^H^H^Hlook (boy, am I glad I'm not). I was thinking about adding a cygwin-set-reply-to opt-in subscription list for people (like me) who always want the reply-to set to the mailing list. It would require a fair amount of rework of the spam blocking software but it is doable. Would that be a useful feature? YES, that would definitely by a useful feature :) rlc -- This life is a test. It is only a test. Had this been an actual life, you would have received further instructions as to what to do and where to go. -- 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/
Updated: pcre-4.5-1
New News: = Version 4.5-1 of the PCRE packages is now available for download. This corresponds to the latest official PCRE release. The only changes applied to this version wrt the canonical version involve the build process. To update your installation: === Run the Setup utility from http://cygwin.com/setup.exe and pick up the proper packages. Problem reports: === Please send reports of any problems related to these packages to [EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a regular basis. Old News: The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. PCRE has its own native API, as well as a set of wrapper functions that correspond to the POSIX regular expression API. The PCRE library is free, even for building commercial software. have a look at http://www.pcre.org for details Port Notes: - version 4.5-1 - Update to canonical 4.5 - version 4.4-2 - Move the Cygwin-special README to the proper location - version 4.4-1 - Patches applied to 4.3-x were largely integrated into the canonical package. The rest of the patches (of course) still apply - version 4.3-4 - Make doc package FHS compliant - version 4.3-3 - Recompile against Cygwin-1.5.0 - version 4.3-2 - Added pcre-config script to pcre-devel package - version 4.3-1 - The same patches as applied to version 4.2-2 were applied to this version. - version 4.2-2 - A slight modification was made to the packaging script to kill a bug that had snuck into the tarballs - version 4.2-1 - The patch I made earlier, which got into the canonical PCRE, worked around using Libtool on Cygwin without there being any need to do so, as Gerrit P. Haase kindly pointed out. With his patch and one by Charles Wilson, the Cygwin build procedure is just like any *NIX - due thanks go to the both of them. - versions prior to 4.2-1 - Anything prior to 4.2-1 was maintained by Corinna Vinschen - any notes on those versions are available in the mail archives. -- Forgetfulness, n.: A gift of God bestowed upon debtors in compensation for their destitution of conscience.
new pcre packages ready for download
The latest versions of the pcre packages are available for download (out since yesterday afternoon) e891737e53e5675f65eea6ba15d7d0ef *pcre-4.5-1-src.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1-src.tar.bz2 04754e6ba8866035ff8b99a9e37e8bcd *pcre-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1.tar.bz2 c332a4f2ad22349e5653f603ca8dbe6b *pcre-devel-4.4-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.4-1.tar.bz2 183eb1137950fb5f82c71cc1b9152457 *pcre-devel-4.4-2.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.4-2.tar.bz2 fe1e4a8b37f9ebc68c2e2bc9b4482349 *pcre-devel-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.5-1.tar.bz2 0e8d550958cf46ac6b7681ab2d22785e *pcre-doc-4.4-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.4-1.tar.bz2 aa218c3a0c7f12fee103bc2baf77756f *pcre-doc-4.4-2.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.4-2.tar.bz2 be168960d6edd3a913e3aabb9984b09d *pcre-doc-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.5-1.tar.bz2 211a9657aae65a15780aaa8247bad7ac *libpcre0-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/libpcre0-4.5-1.tar.bz2 (You can also point Setup to http://rlc.unsane.co.uk to get them, if you want). The only change is the update to the latest canonical version. There are no Cygwin-specific changes to the code for this version (and it builds almost OOTB). I'll announce when it's uploaded. rlc -- The only thing worse than X Windows: (X Windows) - X
Re: new pcre packages ready for download
Severe sleep deprevation combined with a lack of cafeine made me notice rather belatedly that the 4.4 files are there as well.. Please ignore them and just take the files cited here.. e891737e53e5675f65eea6ba15d7d0ef *pcre-4.5-1-src.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1-src.tar.bz2 04754e6ba8866035ff8b99a9e37e8bcd *pcre-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-4.5-1.tar.bz2 fe1e4a8b37f9ebc68c2e2bc9b4482349 *pcre-devel-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-devel-4.5-1.tar.bz2 be168960d6edd3a913e3aabb9984b09d *pcre-doc-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/pcre-doc-4.5-1.tar.bz2 211a9657aae65a15780aaa8247bad7ac *libpcre0-4.5-1.tar.bz2 http://rlc.unsane.co.uk/release/pcre/libpcre0-4.5-1.tar.bz2 prev: 4.4-2 please remove anything older than 4.4-2. Thanks, rlc
Re: Link error using g++ 3.3.1
On Thu, Dec 11, 2003 at 12:40:52PM +0100, Jean-Francois bonastre wrote: I've just install (using cygwin setup) cygwin and g++ dev tool using the latest web install on www.cygnus.com ^^- s/nus/win/g ? When I try to build an exec, I get a link error : /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(libcmain.o)(.text+0x7c): undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status I linked the cygcheck output to this email. Have you verified that whatever you're linking has a main() function? If it does, please post some more useful information about what you're doing, such as the command-line used for the link, a more exact description of what you expect it to do, etc. An undefined reference to [EMAIL PROTECTED] usually means that there is no main() function when trying to link an executable.. HTH rlc -- When you say that you agree to a thing in principle, you mean that you have not the slightest intention of carrying it out in practice. -- Otto Von Bismarck -- 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: Pending Packages List, 2003-12-09
On Tue, Dec 09, 2003 at 05:00:01PM -, Daniel Reed wrote: Package: ploticus 2.11-1 [2003-09-15] +1 vote Package: GraphicsMagick 1.0.4-1 [2003-12-07] Just in case this is not vote-exempt: +1 vote rlc PS: how the checklist for good-to-go reviews coming along? -- Eschew obfuscation.
Re: [ITP] ddd-3.3.8
This definitely has my vote - anything that makes debugging easier is a Good Thing IMHO. rlc On Fri, Dec 05, 2003 at 09:38:15PM -0500, Harold L Hunt II wrote: I would like to contribute and maintain ddd: http://www.gnu.org/software/ddd/ GNU DDD is a graphical front-end for command-line debuggers such as GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, or the Python debugger. Besides ``usual'' front-end features such as viewing source texts, DDD has become famous through its interactive graphical data display, where data structures are displayed as graphs. You can point Cygwin's setup.exe to the following address to install and test ddd: http://www.egr.msu.edu/~huntharo/cygwin/ ***Reviewer's Caveat***: I don't think that the static libiberty.a is supposed to be installed, so I removed the /usr/lib directory in the install step of the build script. cut here -- #!/bin/bash mkdir ddd cd ddd wget \ http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/setup.hint wget \ http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1.tar.bz2 wget \ http://www.egr.msu.edu/~huntharo/cygwin/release/ddd/ddd-3.3.8-1-src.tar.bz2 cut here -- MD5 sums: de2d743b95817745c4227427afec759b *ddd/ddd-3.3.8-1-src.tar.bz2 86cc2b9dff9a4f794dfc6bbe49bf2bbc *ddd/ddd-3.3.8-1.tar.bz2 2c6bec0f95a7c76ee6581133eeab1db6 *ddd/setup.hint Harold -- It's later than you think.
Re: [Review - Good to go] WordNet: An online lexical reference system [Needs 2 more votes]
me too - that makes three :)
On Wed, Dec 03, 2003 at 06:55:40PM -0600, Joshua Daniel Franklin wrote:
I vote pro.
On Wed, Dec 03, 2003 at 07:50:21PM -0500, Harold L Hunt II wrote:
Volker,
I downloaded the source and binary packages, rebuilt from the source,
ran the setup.hint through upset, installed, checked the directory
structure, ran wnb.exe and confirmed that it works and I give the
following review:
Good to go!
I also vote pro. Daniel can upload this as soon as two other people
vote pro.
Harold
Dr. Volker Zell wrote:
Hi
I would like to contribute and maintain the WordNet package:
* http://www.cogsci.princeton.edu/~wn/ (Homepage)
* ftp://ftp.cogsci.princeton.edu/pub/wordnet/2.0/ (Download location)
Ciao
Volker
Here is the setup.hint file:
sdesc: An online lexical reference system
ldesc: WordNet is an online lexical reference system. Word forms in WordNet are
represented in their familiar orthography; word meanings are represented by
synonym
sets (synsets) - lists of synonymous word forms that are interchangeable in some
context. Two kinds of relations are recognized: lexical and semantic. Lexical
relations hold between word forms; semantic relations hold between word
meanings.
category: Text Utils
requires: cygwin tcltk
cut here
#!/bin/bash
mkdir WordNet
cd WordNet
wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/WordNet/setup.hint
wget
http://cygwin.dev.wapme.net/packages/vzell/cygwin/WordNet/WordNet-2.0-1-src.tar.bz2
wget
http://cygwin.dev.wapme.net/packages/vzell/cygwin/WordNet/WordNet-2.0-1.tar.bz2
cut here
--
Democracy is a form of government that substitutes election by the
incompetent many for appointment by the corrupt few.
-- G.B. Shaw
Re: [ITP] ImageMagick
On Wed, Dec 03, 2003 at 11:07:59PM +1100, Gareth Pearce wrote: -Original Message- On Behalf Of Corinna Vinschen Sent: Wednesday, 3 December 2003 10:30 PM Subject: Re: [ITP] ImageMagick On Wed, Dec 03, 2003 at 03:27:48AM -0500, Harold L Hunt II wrote: I would like to contribute and maintain ImageMagick: Yes!-- This is a vote And I thought with Harold packaging it wouldn't need a vote... or I would of already. AFAIK, XFree packages don't need votes. I don't think ImageMagick is an XFree package - is it? rlc
Re: How to execute bash file under /usr/bin despite setting PATH=/us r/local/bin:/usr/bin:/bin:/usr/X11R6/bin:$PATH
On Wed, Dec 03, 2003 at 10:43:23AM +0100, Nguyen, Huu-Dung wrote: Please help me to understand Cygwin because i am an unexperienced user of CygWin I want to start some bash files or *.exe under /usr/bin so i have set in my profile file ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:$PATH ... and put my bash files or *.exe under /usr/bin but i can not start them from anywhere in the Cygwin session. Did you perchange put your files in c:\cygwin\usr\bin ? (assuming you installed in c:\cygwin) If so, you should know that the c:\cygwin\bin directory is mounted to /usr/bin, which makes the contents of c:\cygwin\usr\bin invisible from within the Cygwin environment. This is by design. Move the files to c:\cygwin\bin and you should be OK. Note that in all this, I assume you've installed Cygwin's root in c:\cygwin. If it's in q:\tralala (which is possible, of course) replace every instance of c:\cygwin above with q:\tralala. Why and what can i do to start them from anywhere in the Cygwin session ? If the above doesn't help, look at http://cygwin.com/problems.html to know how to give us more information about you problem :) HTH rlc -- Fraud is the homage that force pays to reason. -- Charles Curtis, A Commonplace Book -- 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: Bash wait indefinitely
Please use cygwin at cygwin dot com for cygwin-related mail. I have set the reply-to header for your convenience. On Mon, Dec 01, 2003 at 12:24:47PM -0800, Antoine Labour wrote: Ronald Landheer-Cieslak wrote: Unfortunately, I don't have any system with more than one CPU, so there's no way I can test it on a system like that and I have not run into any similar problems on any of the systems I have.. (Cygwin or otherwise). I'm afraid someone else will have to debug this, as I don't see that I can do anything - especially if it's hard to debug, only happens on multi-CPU systems and only with complex Bash scripts.. If it is the same problem as I am experiencing, it seems to happen on mono-CPU systems as well. Try this simple script : #!/bin/bash i=0 while true do A=$(basename /bin/sh) i=$(($i+1)) echo $i; done OK, I've run the script on my Cygwin machine and it does hang. Attaching with strace gets me an access violation (trying to read from NULL). Killing strace doesn't kill bash, which tells me it hadn't really attached yet (AFAIK, detaching from a process kills the process in all Windows before XP) It is true, it's hard to reproduce, like any other race. But if you have any insight about the threading model for processes, and how pipes are handled, regarding synchronisation, that'd be helpful. I'm new to the code base, and the learning curve is kind of steep (especially without having access to cygwin-dev archive). Last time I checked, I could download the mbox-format archives from the FTP site.. I'm not all that familiar with the Cygwin threading code either, but I'm kinda familiar with the Bash codebase (since I'm the Cygwin-Bash maintainer 'n all) Attaching with gdb to the hanged Bash process gives me the attached gdb.out. (HTH) rlc BTW: AFAICT this is not a Bash problem: my other Bashes (on Linux) are milling happily.. -- I'm having a tax-deductible experience! I need an energy crunch!! [Switching to thread 1568.0x6a4] (gdb) bt #0 0x78477705 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINNT/System32/NTDLL.DLL #1 0x77e91982 in KERNEL32!GetThreadContext () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x78462b95 in vsnprintf () from /cygdrive/c/WINNT/System32/NTDLL.DLL #3 0x77e787dd in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINNT/system32/KERNEL32.DLL (gdb) thread [Current thread is 3 (thread 1568.0x6a4)] (gdb) thread 1 [Switching to thread 1 (thread 1568.0x630)]#0 0x7846376e in ntdll!ZwClose () from /cygdrive/c/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x7846376e in ntdll!ZwClose () from /cygdrive/c/WINNT/System32/NTDLL.DLL #1 0x77e77738 in KERNEL32!CloseHandle () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x61014fa7 in cygwin_internal () from /usr/bin/cygwin1.dll #3 0x61056a77 in cygwin_winpid_to_pid () from /usr/bin/cygwin1.dll #4 0x61079f46 in cygwin1!close () from /usr/bin/cygwin1.dll #5 0x00425921 in ?? () #6 0x0003 in ?? () #7 0x0001 in ?? () #8 0x0022f96c in ?? () #9 0x0001 in ?? () #10 0x0001 in ?? () #11 0x0002 in ?? () #12 0x0001 in ?? () (gdb) thread 2 [Switching to thread 2 (thread 1568.0x4ec)]#0 0x784637b2 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x784637b2 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINNT/System32/NTDLL.DLL #1 0x77e77ab7 in WaitForMultipleObjectsEx () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #2 0x77e7a31d in WaitForMultipleObjects () from /cygdrive/c/WINNT/system32/KERNEL32.DLL #3 0x00adfe84 in ?? () #4 0x0001 in ?? () (gdb) -- 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: Doubt and Request
To download and install Cygwin and its packages, follow the instructions here: * http://cygwin.com/cygwin-ug-net/setup-net.html the part of the users guide on setting up Cygwin * http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html the users guide's TOC * http://cygwin.com/faq/faq_2.html#SEC8 the part of the FAQ on installing Cygwin * http://cygwin.com/faq.html the FAQ itself * http://cygwin.com/packages/ a search engine you can use to find programs/files in the packages to know what to install * http://cygwin.com/lists.html the portal to the mailing list archives * http://cygwin.com/ml/cygwin/ the archives of this list Please follow these links to find the information you need. If you still have questions after all that, feel free to ask, but try to be precise :) HTH rlc On Mon, Dec 01, 2003 at 12:25:09PM +0530, kowtham prabu wrote: Hello sir, i have downloaded Cygwin Free Software from the Web and i installed it in my Pc. i don't know how to install and run the C programs in windows using Cygwin Software. Pls Help me and guide me with some procedures Thanks in Advance. Your's Sincerly Kowtham Prabu.C _ Express your Digital Self. Win fabulous prizes. http://www.msn.co.in/DigitalSelf/ Enter this cool contest. -- 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/ -- There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- 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: Bash wait indefinitely
Unfortunately, I don't have any system with more than one CPU, so there's no way I can test it on a system like that and I have not run into any similar problems on any of the systems I have.. (Cygwin or otherwise). I'm afraid someone else will have to debug this, as I don't see that I can do anything - especially if it's hard to debug, only happens on multi-CPU systems and only with complex Bash scripts.. Sorry, rlc On Fri, Nov 28, 2003 at 03:13:45PM -0500, Nicholas Wourms wrote: news.gmane.org wrote: I'm running in concurrences 5 complex bash batch, and sometimes (2 times on 3) one or more (very rarely) batch stop to do something. I've put a lot of trace to see where is the problem, but seems rarely arrived at the same line of code. I've also tried to use strace tool, but strace hang rapidly. For the last few weeks I've been experiencing the same, and the offenders always seem to be either bash (not ash) or make. It is important to note that I track cygwin's CVS head, so I had chalked it up to the on-going signal work. I've found that running deep `make`s or running the autotools in succession (such as in the case of triggering the AM_MAINTAINER_MODE routines) often triggers this problem for me on my Dual Athlon MP 2400+ Win2K box :-(. I've been extremely busy working on other things, I just grumble, kill the deadlocked process and its children, then restart the parent. Attempting to debug gdb/strace, as you've discovered, is quite fruitless. Cheers, Nicholas -- 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/
Re: please do help me out
Here are some pointers as to where you might want to look for detailed help: * http://cygwin.com/xfree/ the site dedicated to XFree on Cygwin * http://cygwin.com/ml/cygwin-xfree/ the archives of the list dedicated to XFree on Cygwin (where this question would be on-topic) * http://cygwin.com/xfree/docs/ug/ The users guide of XFree for Cygwin * http://xfree86.cygwin.com/docs/faq/ The FAQ for XFree on Cygwin Personally, I don't know squat about XFree for Cygwin - I'm a console user all the way (and I don't have XFree on my Linux boxes either), but I found these URLs by just clicking on XFree86 at the left on the cygwin.com home page (right under Software. You could have (and IMHO should have) done the same thing :) A look at the mailing lists page would have told you that Questions about the Cygwin/XFree86 project (or any X-related questions for cygwin) should go to the cygwin-xfree mailing list (see below)., and would have given you three of the URLs I gave you above :) HTH rlc On Fri, Nov 28, 2003 at 06:05:02PM +0530, schumii srinivasan wrote: hi everybody, i am a new user to this group and hope there are lots to help me out here. i am doing my theses in MANETs and for that i am using the ns-2 simulator. this ns-2 needs cygwin with X-free 86 in it. i think iam able to install cygwin without any problem but when i check for this x-free86 using a command which is given in the cygwin documentation it does not work and its replying that its not being installed properly. can anyone please giveme a clear idea and method to install this cygwin stuff and make xfre86 also in it safely. plese do anybody help me as soon as possible. ;with regards, vishak srinivasan _ Enjoy shopping online? Get this e credit card. http://server1.msn.co.in/features/amex/ It cuts cost adds value! -- 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/ -- Obstacles are what you see when you take your eyes off your goal. -- 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: Running a script from Bash
You run a script by running its interpreter (at least if its outside the wonderful world of Cygwin). What you need in your environment variables depends on what you need to run the script and what its interpreter expects of its environment. Read the documentation of the interpreter and the script itself to find out what you need - there's no information anywhere in your mail that gives me a clue about a more precise answer.. rlc On Thu, Nov 27, 2003 at 11:24:28AM -0800, Ashman,Tim [PYR] wrote: In my first posting today, I was using an Octave script in explaining my problem of how to run an external script from Cygwin in general. Putting Octave aside for a moment, what do I need to do (PATH setting, script header, etc) to run any external script from a bash script? Basically, I would like a bash script located at C:/cygwin/bin to call a script in a different language that is located somewhere else on my computer. Sorry about the confusion, thanks again for your help... -- 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: Pending Packages List, 2003-11-26
On Wed, Nov 26, 2003 at 05:51:24PM -, Daniel Reed wrote: rdesktop 1.3.0-1 [2003-11-08] Description: client for Windows terminal server. Remote desktop display Proposer: Jari Aalto Proposal: mailto:[EMAIL PROTECTED] http://tierra.dyndns.org:81/cygwin/rdesktop/rdesktop-1.3.0-1.tar.bz2 http://tierra.dyndns.org:81/cygwin/rdesktop/rdesktop-1.3.0-1-src.tar.bz2 [no hint] Aye votes: Harold L Hunt II (cygwin-apps-thread.12044) [1/3] Abe Backus (cygwin-apps-thread.12051) [2/3] Status: Package available. HOLD-UPS: Not enough votes (need 1 more). No good to go review. I vote for this. rlc
Re: newby stupid question - cat mutiple files to new piped output files
On Wed, Nov 26, 2003 at 10:42:58AM -0500, Igor Pechtchanski wrote: On Wed, 26 Nov 2003, Ronald Landheer-Cieslak wrote: On Wed, Nov 26, 2003 at 04:55:34AM -0500, c wrote: Just started to get somewhere until i wanted to cat a heap of csv files and then send the unique records to a new file. I thought it couldnt be to hard but now my brain hurts. Can anyone help me with a line of code that will do the command below '$ cat d:/pc1/filename.csv |uniq d:/pc1/newfilename.csv' but i want it do it repeatidly for every .csv file in that directory? This has nothing to do with Cygwin, but hey.. for i in /cygdrive/d/pc1/*.csv; do cat $i | uniq /cygdrive/d/pc1/newfilename.csv done Umm, surely you meant cat /cygdrive/d/pc1/*.csv | sort | uniq /cygdrive/d/pc1/newfilename.csv right? Ehm, no, not that one.. Or, at the very least, for i in /cygdrive/d/pc1/*.csv; do cat $i | uniq /cygdrive/d/pc1/newfilename.csv done Type-o for the missing '' - thanks for the vigilance :) The goals of the OP weren't very clearly stated, so he might have wanted to do for i in /cygdrive/d/pc1/*.csv; do cat $i | uniq /cygdrive/d/pc1/new$i.csv done instead. Tha ambiguity (and the fact that this has nothing to do with Cygwin) was why I told him to take a look at the advanced Bash scripting guide - it's very informative and doesn't require you to be advanced before you start at the Bash scripting :) rlc -- 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: non-setup information in setup.hint (was Re: Maintainers/Packages List, 2003-11-22)
On Tue, Nov 25, 2003 at 08:40:43PM -0500, Igor Pechtchanski wrote: BTW, another piece of non-setup information that might be useful is an up for adoption (or orphaned) flag. Why not make it a setup flag? Make a nasty little pop-up box pop up when you install an orphaned package - something like The package ... is up for adoption! Please take a look at http://cygwin.com/setup.html to see how you can help out! Perhaps add a new category orphaned as well, listing all orphaned packages and offering to download the source by default.. JAT.. rlc
Apparent problem with tcsh's cd [was: Re: Where am I anyway?]
Hello Dai, Your subject line wasn't very explicit in what you were talking about, so I guess most people on the list will have skipped your message entirely. It just showed up in my scanning my mailbox for bash.. Anyway, you don't give us any information about your Cygwin installation: the version of tcsh you're using, the version of Cygwin you're using, etc. Please take a look at http://cygwin.com/problems.html to find out how we like our bug reports :) As you're not using Bash (or PCRE, or splint, or Aspell-en) I'll leave it to the wisdom of the tcsh maintainer to help you out :) Good luck :) rlc On Tue, Nov 25, 2003 at 11:23:03AM -0800, Dai Itasaka wrote: [EMAIL PROTECTED] cd c:/temp/foo [EMAIL PROTECTED] ls bar/ foo.file [EMAIL PROTECTED] cd bar [EMAIL PROTECTED] ls bar.file [EMAIL PROTECTED] cd c:/temp/foo/bar [EMAIL PROTECTED] ls bar.file [EMAIL PROTECTED] ls .. bar/ foo.file [EMAIL PROTECTED] cd c:/temp/foo/bar/ [EMAIL PROTECTED] ls bar.file [EMAIL PROTECTED] ls .. bar.file [EMAIL PROTECTED] cd .. [EMAIL PROTECTED] ls bar.file [EMAIL PROTECTED] ls .. bar/ foo.file [EMAIL PROTECTED] If the directory name you give cd meets this criteria: - start with a drive letter - end with a slash then it looks like cd takes you where you want to go but it really takes you one below so that you have to climb up one level to be safe. Bash doesn't observe this problem. This is using tcsh. -- 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/ -- Love is in the offing. Be affectionate to one who adores you. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash and rxvt exiting with .NET
On Tue, Nov 25, 2003 at 10:57:16PM -0600, [EMAIL PROTECTED] wrote: Howdy. Hello :) I'm using .NET 1.1 in development. I have tried using both the standard bash cygwin terminal and rxvt with limited success. Whenever I run my .NET console application from within Cygwin and that application generates an exception, the Cygwin session ends after I cancel the Do You Want to Debug? dialog. The entire terminal disappears. You're giving us very little information about your system. Could you take a look at http://cygwin.com/problems.html and fill in the blanks? BTW: I don't have any .NET software so I'm afraid I probably won't be able to reproduce your problem.. rlc -- The goal of science is to build better mousetraps. The goal of nature is to build better mice. -- 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: newby stupid question - cat mutiple files to new piped output files
On Wed, Nov 26, 2003 at 04:55:34AM -0500, c wrote: Just started to get somewhere until i wanted to cat a heap of csv files and then send the unique records to a new file. I thought it couldnt be to hard but now my brain hurts. Can anyone help me with a line of code that will do the command below '$ cat d:/pc1/filename.csv |uniq d:/pc1/newfilename.csv' but i want it do it repeatidly for every .csv file in that directory? This has nothing to do with Cygwin, but hey.. for i in /cygdrive/d/pc1/*.csv; do cat $i | uniq /cygdrive/d/pc1/newfilename.csv done This will work once, because the new files won't be there yet. After that, the *.csv will pick up the new files as well.. Take a look at the Advanced Bash scripting guide which you can find at http://tldp.org for info on how to do this kind of thing correctly.. HTH rlc -- Dave Mack: Your stupidity, Allen, is simply not up to par. Allen Gwinn:Yours is. -- 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: Maintainers/Packages List, 2003-11-22
On Mon, Nov 24, 2003 at 12:37:21PM -0500, Igor Pechtchanski wrote: On Mon, 24 Nov 2003, Ronald Landheer-Cieslak wrote: On Sat, Nov 22, 2003 at 05:13:04PM -, Daniel Reed wrote: splint Elfyn McBratney Has someone already proposed to take over maintainership of this package? If not, I'd be willing to do so.. Go ahead. I was planning to look at it at some future point, but feel free to take over -- I'm not going to get to it for a while. OK. Splint is at the same version as we have in the Cygwin distribution, and there is only one (small) patch that should go upstream, so I won't make a new release just for the maintainer change (unless someone asks me to). I will let the splint people know that I'll be maintaining splint for Cygwin and will give them Elfyn's patch. rlc -- An engineer is someone who does list processing in FORTRAN.
Re: Maintainers/Packages List, 2003-11-22
On Sat, Nov 22, 2003 at 05:13:04PM -, Daniel Reed wrote: splint Elfyn McBratney Has someone already proposed to take over maintainership of this package? If not, I'd be willing to do so.. rlc
Re: bash v2.05b.0 + nmake v7.10.3077 problem
On Thu, Nov 13, 2003 at 06:21:33PM +0100, Hannu E K Nevalainen wrote: Not that I see this to be important; 1. I see CRLF line endings. That confirms that there is something wrong elsewhere (probably at my ISP or someplace between there and the Cygwin list) as where you see cr nl, I see nl nl.. AFAIK, none of the software I use does any mangling in this fashion (and I haven't had the problem before..) 2. No double linefeeds in 'less' nor in the old Win-GUI editor I use (name: PFE). I've downloaded the file from the archives just to make sure I have the right one somewhere. It doesn't change much, though: I still don't see much of anything that might be suspicious in the file. A minimal testcase would be nice.. rlc -- Pollyanna's Educational Constant: The hyperactive child is never absent. -- 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: bash v2.05b.0 + nmake v7.10.3077 problem
Hello Lars, On Wed, Nov 12, 2003 at 12:15:34PM +0100, Lars Monecke wrote: I updated to msvc 7.1. Before I used msvc 6.0 with no problems in compiling from bash. Now nmake has problems to compile in the bash enviroment. The following error occured: Makefile(147) : fatal error U1054: cannot create inline file '' Has anyone the same problems? Is it a problem of nmake or my makefile (i use qmake to generate my makefiles)? You're giving us very little (way too little) information to help you in any way. Have a look at http://cygwin.com/problems.html and perhaps post things like: * the Makefile (especially line 147 seems to be of interest) * a step-by-step description of what you're doing * whether it works when invoking nmake from the Windows command shell (will help to find out whether it has anything to do with Bash, Cygwin, etc.) rlc -- 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: bash v2.05b.0 + nmake v7.10.3077 problem
The attachment you sent has a lot of blank lines in it (at least when I look at it on my Linux box) - is that normal? (i.e. one in two lines is blank). Other than that, I see nothing suspicious in the file.. Could you provide a minimal testcase that reproduces the behaviour? On Thu, Nov 13, 2003 at 01:28:38PM +0100, Lars Monecke wrote: Hello Ronald, here some additional information... Ronald Landheer-Cieslak wrote: * the Makefile (especially line 147 seems to be of interest) Please refer to attachment. But line 147 seems to the end of the file... The Makefile is generated by qmake 1.06c. * a step-by-step description of what you're doing here a the command history: $ qmake $ nmake clean $ nmake The implementation files were compiled but the link command (or before) ^^^ Is it always the same command? If so, which? failed with fatal error U1054. .. and the filename of the file it wants to create is empty? odd.. If i open then a cmd and switch to the directory and type nmake, the lib will be linked. I can reproduce this on another machine. * whether it works when invoking nmake from the Windows command shell My compilation works fine with a normal command shell. I diffed the generated Makefiles (under bash and cmd) and the only difference is the uppercase of the c: drive-letter. Some more enviroments (i can send you see full cygcheck.out by email): Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Package Version _update-info-dir 00223-1 base-files 2.6-1 cygwin 1.5.5-1 bash 2.05b-16 I don't know much about nmake, but the only reason I see for it failing under Bash and not under cmd would be a difference in environment.. A minimal test case to reproduce the problem would be nice.. rlc -- Floggings will continue until morale improves. -- anonymous flyer being distributed at Exxon USA -- 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: bash v2.05b.0 + nmake v7.10.3077 problem
On Thu, Nov 13, 2003 at 04:38:17PM +0100, Hannu E K Nevalainen wrote: From: Ronald Landheer-Cieslak Sent: Thursday, November 13, 2003 5:22 PM The attachment you sent has a lot of blank lines in it (at least when I look at it on my Linux box) - is that normal? (i.e. one in two lines is blank). Typical for line endings beeing CRLF - and loading such a file into an editor/viewer that dosn't 'handle' this in a sane manner. i.e. Editor/viewer dependant. That would be right if 1. I didn't use vi 2. I hasn't tried dos2unix on the file rlc -- You have been selected for a secret mission. -- 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: Pending Packages List, 2003-10-21
On Mon, Oct 27, 2003 at 12:43:37PM -0500, Christopher Faylor wrote: On Mon, Oct 27, 2003 at 01:14:46PM +0100, Ronald Landheer-Cieslak wrote: On Wed, Oct 22, 2003 at 08:30:32AM +0200, Gerrit P. Haase wrote: Am Dienstag, 21. Oktober 2003 um 19:00 schriebst du: This is the list of pending packages as of Tuesday, October 21, 2003. Package: d 1.2.0-1 Description: The Directory Lister Proposer: Yaakov Selkowitz Proposal: mailto:[EMAIL PROTECTED] Reviews: Gerrit P. Haase (cygwin-apps-get.11476) Aye votes: Gerrit P. Haase (cygwin-apps-get.11476) [1/3] Status: Package available. Reviewed. HOLD-UPS: Not enough votes (need 2 more). How much ITPs where seen without a real interest or ability from the maintainer tobe? This one is not one of these, I like this tool, that was the reason I was voting, even if I wouldn't use it, I think it is nice to have an alternative to 'ls', maybe other people think similar and want to give it a try? The most packages are really needed to develop applications and to maintain packages, but OTOH Cygwin should respect the users who just want to use it as their favourite system to drive the Windows subsystem, so give them tools to use this system. Want to say, vote if you don't think it is a really bad idea to have some alternative directory lister (questions like: who needs it when we have ls? are well known, but these answers are not a veto!). I agree that diversity is a Good Thing. I also agree that it may be a good idea to introduce such diversity (more of it) into the Cygwin Net distribution Have we already talked about why this package is better than 'ls'? If it is just another directory lister with different options then I don't see a need for it. Also, if it isn't part of any other linux or unix distribution then it doesn't really fit into the core goal for cygwin. Anyway, I'm not going to veto this, but I am going to register a -1 vote until this is clarified. If it has already been discussed then I apologize. I haven't been following closely. I don't think it's been discussed on-list, but the reason I voted for it despite me not going to use it because I like ls enough as is, is that it actually does add some functionalities - most notably the fact that it wastes less space in the output than ls does (which I agree can come in handy), it lists directories first (which is increases visibility of the directory contents) and gives a very clear summary of the directory contents. Personally, I'm no fan of ls any more than I am of this lister: I just happen to know ls an be used to it. I can see how the features added by this lister can be interesting to other users, and I think that that, in itself, is enough reason to vote for a package that has a willing maintainer and is relatively well-written (taken a look at the code). rlc -- Keep the number of passes in a compiler to a minimum. -- D. Gries
Re: Maintainers/Packages List
libpcre0 is built from pcre as well.. setup.ini/hint should note that. If it doesn't, there's a bug. rlc
Re: Pending Packages List, 2003-10-21
On Wed, Oct 22, 2003 at 08:30:32AM +0200, Gerrit P. Haase wrote: Am Dienstag, 21. Oktober 2003 um 19:00 schriebst du: This is the list of pending packages as of Tuesday, October 21, 2003. Package: d 1.2.0-1 Description: The Directory Lister Proposer: Yaakov Selkowitz Proposal: mailto:[EMAIL PROTECTED] Reviews: Gerrit P. Haase (cygwin-apps-get.11476) Aye votes: Gerrit P. Haase (cygwin-apps-get.11476) [1/3] Status: Package available. Reviewed. HOLD-UPS: Not enough votes (need 2 more). How much ITPs where seen without a real interest or ability from the maintainer tobe? This one is not one of these, I like this tool, that was the reason I was voting, even if I wouldn't use it, I think it is nice to have an alternative to 'ls', maybe other people think similar and want to give it a try? The most packages are really needed to develop applications and to maintain packages, but OTOH Cygwin should respect the users who just want to use it as their favourite system to drive the Windows subsystem, so give them tools to use this system. Want to say, vote if you don't think it is a really bad idea to have some alternative directory lister (questions like: who needs it when we have ls? are well known, but these answers are not a veto!). I agree that diversity is a Good Thing. I also agree that it may be a good idea to introduce such diversity (more of it) into the Cygwin Net distribution I've now read the info file that comes with the package and tested it on my system. I don't think I'll use it often, but I don't think it's a bad idea to put it in the net distribution either. You've convinced me, I'm in a good mood or whatever - this has my vote. rlc -- Things fall apart; the centre cannot hold.
Re: New Bash ready for upload
Sorry for the late reply - I just became a father last monday night :) Anyway, -15 is prev, -13 can be removed. The difference between -13 and -15 is that the canonical patches released between -13 and -15 are applied to -15, and there's been a maintainer and packaging method change, but I don't think any of those changes will want people to keep -13 rather than -15. I'll send an announcement shortly. rlc On Mon, Oct 20, 2003 at 03:58:22PM -0400, Daniel Reed wrote: On 2003-10-20T15:22+0200, Ronald Landheer-Cieslak wrote: ) I've applied cgf's patch to Bash and test-driven it on my machine. The new ) version is available here: ) ) e148fb06b6c856a591a985d86361da15 *bash-2.05b-16-src.tar.bz2 ) http://rlc.unsane.co.uk/release/bash/bash-2.05b-16-src.tar.bz2 ) 837f987c5c5cbceb773bf14a32060bac *bash-2.05b-16.tar.bz2 ) http://rlc.unsane.co.uk/release/bash/bash-2.05b-16.tar.bz2 Uploaded. Please send an announcement once you have had a chance to verify correct installation with setup.exe. Should I remove 2.05b-13? Corinna asked earlier (I was waiting for a reply before pushing) which is why I am unsure. There are no overrides in setup.hint, so everyone should be running 2.05b-15 at present, and should automatically upgrade to 2.05b-16 the next time setup is run. Thanks for the update, -- Daniel Reed [EMAIL PROTECTED] http://naim-users.org/nmlorg/ http://naim.n.ml.org/ A professor is one who talks in someone else's sleep. -- Code like that would not pass through anybody's yuck-o-meter. - Linus Torvalds about design on linux-kernel
Re: pwd option to return windows path
This thread, though getting on my nerves, actually has a relatively interesting question in it. I think the answer is kinda obvious, though.. On Wed, Oct 22, 2003 at 11:36:07AM -0400, Patrick J. LoPresti wrote: P.S. Speaking of special treatment, how come Cygwin is the only free software project whose maintainers say PTC instead of PGA? How naive all those other maintainers must be! if the other projects say they will greatfully accept patches, they will also say that they will consider those patches beforrree greatfully accepting them - not doing so would either be lying or being incredably silly in the politics towards patches. The Cygwin maintainers are honest, hard-working people that have made some great ideas happen. Part of their honesty compells them to tell you that though patches will be thoughtfully considered, not all of them will be accepted - but those that are are done so greatfully. For a patch to be considered, all the technical and legal problems that the patch may impose on the Cygwin developers must be dealt with. Not doing so would eventually kill the project. Personally, I think it is a Good Thing to be honesty and to have clear rules/procedures about how to handle development and accepting patches. I'm not saying other maintainers are naive, dishonest or stupid or anything, I'm just saying they also TC the Ps before GAing them :) rlc -- Everything takes longer, costs more, and is less useful. -- Erwin Tomash -- 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: Q: mixing MSVC++ and gcc C++ libs/dlls ?
On Thu, Oct 23, 2003 at 03:21:32PM +0200, Heiko Nardmann wrote: Hi! The FAQ tells me that only C object files can be mixed. Is this true for MS .NET and gcc 3.x since I expect both to be conform to the ABI standard ? What ABI standard would that be? Anyway, gcc and MSVC don't use the same name mangling (decoration) schemes for C++ so you will not be able to mix the two. Also note that different versions if g++ don't always mix well either.. HTH rlc -- 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: Q: ACE library for cygwin?
On Thu, Oct 23, 2003 at 03:22:27PM +0200, Heiko Nardmann wrote: Did anyone build the ACE library for Cygwin already? AFAIK, no. I haven't actually checked the package list, though, but it doesn't ring any bells. Do you ITP it? Of course, you can find the entire package list at cygwin.com.. rlc -- 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/
[ANNOUNCEMENT] Updated Cygwin package: bash-2.05b-16
New News: = Version 2.05b-16 of the Bash package is now available for download. This is a bugfix release relative to 2.05b-15, and fixes the bug reported and patched in http://www.cygwin.com/ml/cygwin/2003-10/msg01166.html. To update your installation: === Run the Setup utility from http://cygwin.com/setup.exe and pick up the proper packages. Problem reports: === Please send reports of any problems related to these packages to [EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a regular basis. Old News: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. Port Notes: == - version 2.05b-16 - Applied the patch provided by cgf in http://www.cygwin.com/ml/cygwin/2003-10/msg01166.html - version 2.05b-15 - Applied a temporary patch to fix the problem reported in http://www.cygwin.com/ml/cygwin/2003-09/msg00822.html - version 2.05b-14 - Additional canonical patches 5 through 7 applied - version 2.05b-13 and earlier - Earlier versions were maintained by Corinna Vinschen. The history may be found in the cygwin-announce archives. -- 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/
New Bash ready for upload
I've applied cgf's patch to Bash and test-driven it on my machine. The new version is available here: e148fb06b6c856a591a985d86361da15 *bash-2.05b-16-src.tar.bz2 http://rlc.unsane.co.uk/release/bash/bash-2.05b-16-src.tar.bz2 837f987c5c5cbceb773bf14a32060bac *bash-2.05b-16.tar.bz2 http://rlc.unsane.co.uk/release/bash/bash-2.05b-16.tar.bz2 -- firewall needs cooling
Re: cygpath hangings: A fix - bash patch enclosed -- bash maintainer please note!
I'll apply your patch and release a new Bash version shortly
rlc
On Sat, Oct 18, 2003 at 01:58:36AM -0400, Christopher Faylor wrote:
On Wed, Oct 15, 2003 at 04:30:12PM -0400, Christopher Faylor wrote:
I just managed to duplicate the problem on my system at work.
Stay tuned.
I managed to duplicate it at home by booting into W2K, too. That meant
I didn't have to feel guilty about working on this at work. :-)
This should fix the problem. Bash wasn't closing the read end of a pipe
in some situations. I'm not sure why that would cause some programs to
hang but the following patch fixes the problem. I think it provides
more robust code than what was in bash previously, too.
Ronald, if you agree with this patch, could you release a new version of
bash, ASAP? If you don't agree with the patch, then please let me
(aka the cygwin list) know soon since I'm going to be submitting it
upstream ASAP.
cgf
2003-10-18 Christopher Faylor [EMAIL PROTECTED]
* subst.c (command_substitute): Guard against opening a pipe handle in
stdin/stdout/stderr since they may be closed and keeping the pipe
handle open in a subprocess will cause hangs.
--- subst.c.orig 2003-10-15 15:09:01.0 -0400
+++ subst.c 2003-10-18 01:47:49.737056307 -0400
@@ -3716,6 +3716,7 @@ command_substitute (string, quoted)
pid_t pid, old_pid, old_pipeline_pgrp;
char *istring;
int result, fildes[2], function_value;
+ int i, closeit[3];
istring = (char *)NULL;
@@ -3742,6 +3743,16 @@ command_substitute (string, quoted)
if (subst_assign_varlist == 0 || garglist == 0)
maybe_make_export_env ();/* XXX */
+
+ for (i = 0; i = 2; i++)
+if (fcntl (i, F_GETFD, result) != -1)
+ closeit[i] = 0;
+else
+ {
+ open (/dev/null, O_RDONLY);
+ closeit[i] = 1;
+ }
+
/* Pipe the output of executing STRING into the current shell. */
if (pipe (fildes) 0)
{
@@ -3749,6 +3760,10 @@ command_substitute (string, quoted)
goto error_exit;
}
+ for (i = 0; i = 2; i++)
+if (closeit[i])
+ close (i);
+
old_pid = last_made_pid;
#if defined (JOB_CONTROL)
old_pipeline_pgrp = pipeline_pgrp;
@@ -3793,21 +3808,8 @@ command_substitute (string, quoted)
exit (EXECUTION_FAILURE);
}
- /* If standard output is closed in the parent shell
- (such as after `exec -'), file descriptor 1 will be
- the lowest available file descriptor, and end up in
- fildes[0]. This can happen for stdin and stderr as well,
- but stdout is more important -- it will cause no output
- to be generated from this command. */
- if ((fildes[1] != fileno (stdin))
- (fildes[1] != fileno (stdout))
- (fildes[1] != fileno (stderr)))
- close (fildes[1]);
-
- if ((fildes[0] != fileno (stdin))
- (fildes[0] != fileno (stdout))
- (fildes[0] != fileno (stderr)))
- close (fildes[0]);
+ close (fildes[1]);
+ close (fildes[0]);
/* The currently executing shell is not interactive. */
interactive = 0;
--
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/
--
If that man in the PTL is such a healer, why can't he make his wife's
hairdo go down?
-- Robin Williams
--
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: cygpath hangings: A fix - bash patch enclosed -- bash maintainer please note!
I've just checked the patch a wee bit closer - it looks OK to me. If you want
to push it upstream, please go ahead :)
I'm wrapping up release -16 now. I'll make it available for upload on -apps
ASAP.
Thanks,
rlc
On Sat, Oct 18, 2003 at 01:58:36AM -0400, Christopher Faylor wrote:
On Wed, Oct 15, 2003 at 04:30:12PM -0400, Christopher Faylor wrote:
I just managed to duplicate the problem on my system at work.
Stay tuned.
I managed to duplicate it at home by booting into W2K, too. That meant
I didn't have to feel guilty about working on this at work. :-)
This should fix the problem. Bash wasn't closing the read end of a pipe
in some situations. I'm not sure why that would cause some programs to
hang but the following patch fixes the problem. I think it provides
more robust code than what was in bash previously, too.
Ronald, if you agree with this patch, could you release a new version of
bash, ASAP? If you don't agree with the patch, then please let me
(aka the cygwin list) know soon since I'm going to be submitting it
upstream ASAP.
cgf
2003-10-18 Christopher Faylor [EMAIL PROTECTED]
* subst.c (command_substitute): Guard against opening a pipe handle in
stdin/stdout/stderr since they may be closed and keeping the pipe
handle open in a subprocess will cause hangs.
--- subst.c.orig 2003-10-15 15:09:01.0 -0400
+++ subst.c 2003-10-18 01:47:49.737056307 -0400
@@ -3716,6 +3716,7 @@ command_substitute (string, quoted)
pid_t pid, old_pid, old_pipeline_pgrp;
char *istring;
int result, fildes[2], function_value;
+ int i, closeit[3];
istring = (char *)NULL;
@@ -3742,6 +3743,16 @@ command_substitute (string, quoted)
if (subst_assign_varlist == 0 || garglist == 0)
maybe_make_export_env ();/* XXX */
+
+ for (i = 0; i = 2; i++)
+if (fcntl (i, F_GETFD, result) != -1)
+ closeit[i] = 0;
+else
+ {
+ open (/dev/null, O_RDONLY);
+ closeit[i] = 1;
+ }
+
/* Pipe the output of executing STRING into the current shell. */
if (pipe (fildes) 0)
{
@@ -3749,6 +3760,10 @@ command_substitute (string, quoted)
goto error_exit;
}
+ for (i = 0; i = 2; i++)
+if (closeit[i])
+ close (i);
+
old_pid = last_made_pid;
#if defined (JOB_CONTROL)
old_pipeline_pgrp = pipeline_pgrp;
@@ -3793,21 +3808,8 @@ command_substitute (string, quoted)
exit (EXECUTION_FAILURE);
}
- /* If standard output is closed in the parent shell
- (such as after `exec -'), file descriptor 1 will be
- the lowest available file descriptor, and end up in
- fildes[0]. This can happen for stdin and stderr as well,
- but stdout is more important -- it will cause no output
- to be generated from this command. */
- if ((fildes[1] != fileno (stdin))
- (fildes[1] != fileno (stdout))
- (fildes[1] != fileno (stderr)))
- close (fildes[1]);
-
- if ((fildes[0] != fileno (stdin))
- (fildes[0] != fileno (stdout))
- (fildes[0] != fileno (stderr)))
- close (fildes[0]);
+ close (fildes[1]);
+ close (fildes[0]);
/* The currently executing shell is not interactive. */
interactive = 0;
--
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/
--
We all dream of being the darling of everybody's darling.
--
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: bsd-games--one package or many?
Personally, I would certainly prefer splitting up the package - especially
if the diff games have different dependencies.
To download all the games, you can simply download the entire category,
so I don't think we need a single package that depends on all the games.
OTOH you might want such a package if you want to build the games from a
single source tree.
WFIW, you stand a very good chance at getting the minimum three votes and one
review if you do decide to ITP one or more games.
rlc
NB: for the non-free games, remember anything linked to Cygwin is GPLed. If
the original license doesn't allow that, you can't package the game(s).
On Thu, Oct 16, 2003 at 07:05:26PM -0600, Aaron V. Humphrey wrote:
Greetings,
I'm fairly new to cygwin-apps, but I've been lurking on the main cygwin
list for a few months. Subscribed to the digest, so it never seems
worth actually replying to anything, which is probably all to the good.
I've been considering porting bsd-games to Cygwin, and recently managed
to stop considering and actually do something about it. I've gotten the
code to compile, though sometimes only by commenting out things like
flock() calls(fcntl() research is still forthcoming). I also managed to
link in err.c through a somewhat hamhanded approach that I'm not happy
with. I think I've also managed to track the code to its upstream
source.
It has occurred to me, though, to wonder whether bsd-games would be best
done as a single monolithic package, or as a number of smaller packages,
per game or the like.
If it was a single package, then it would take up less space on the
packages list, and it would be easier to synch it up with release numbers
from sites like Debian. It's also a group of programs that traditionally
go together.
On the other hand, three of the programs(wtf, fortune, and robots)have
already been released as separate packages. If a bsd-games package was
then added, should they be merged in? Left out? Added as dependencies?
Some of the programs are ncurses-dependent, and some are not. factor
can be built to depend on openssh(?) to use its factoring routines, but
I'd hesitate to make the whole package dependent on that. Some of the
programs are not really game-like(number, for instance).
I know that Debian has also split up the package because of licensing
uncertainties; I think only rogue is on the bsd-games-nonfree package,
but I think there are others that have been left out of the packages
entirely because of unclear licensing. I don't know if that's an issue
for Cygwin.
I also harbour some doubts about the legality of propagating monop, for
example, which is surely trademarked or copyrighted or something by the
makes of the Monopoly boardgame.
Also, if it's done as smaller packages, it'd be easier for me as a
first-time packager, and I'd be able to get something ready to release
more quickly.
So I'm leaning towards multiple packages, but I'd like to get opinions
from others before I commit to it.
One thing that I also wondered about was words, as in
/usr{/share}/dict/words. Wordlists are required for hangman and
boggle, at least, and as far as I can tell aren't available in the
Cygwin installation anywhere. Is that another package people might be
interested in? If I can find a wordlist I'm happy with, anyway...
--
--Alfvaen(Web page: http://www.telusplanet.net/public/alfvaen/)
Song In My Head--Barenaked Ladies:Another Postcard
Current Book--Jean M. Auel:The Plains of Passage
Wind that speaks to the leaves, telling stories that no one believes
--
If they can make penicillin out of moldy bread, they can sure make
something out of you.
-- Muhammad Ali
Re: ash does not understand '~'
On Fri, Oct 17, 2003 at 05:48:12AM -0700, Brian Dessent wrote: Jörg Schaible wrote: Corinna Vinschen wrote on Friday, October 17, 2003 1:04 PM: On Fri, Oct 17, 2003 at 12:37:10PM +0200, J?rg Schaible wrote: BTW: It does also not know the [ ] syntax for a built-in test, you always have to use test: if test -f /etc/hosts; then echo /etc/hosts exist! fi Beep. Wrong. It knows [ ] Corinna Did that change at some point? I remember having really big problems writing scripts running on a on Solaris, Linux and Cygwin some years ago g and IIRC it was basically because of ash at that time ... I thought this was resolved by making '/bin/[' a symlink to /bin/test. This gives the appearance of the shell supporting [ ] even though it's really just running a program just as if you had used 'test'. How does that take care of the closing `]' ? rlc -- No-one would remember the Good Samaritan if he had only had good intentions. He had money as well. -- Margaret Thatcher -- 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: Where does the 'time' (shell keyword) write?
$ bash -c 'time ls ../ls.out' 2 ../time.out HTH rlc On Thu, Oct 16, 2003 at 02:01:20PM +0200, Alex Vinokur wrote: $ type time time is a shell keyword $ time ls dummy1 dummy2 real0m0.040s user0m0.020s sys 0m0.040s $ time ls zzz real0m0.040s user0m0.020s sys 0m0.040s // So, 'time' doesn't write to stdin (?!) $ time ls 2 zzz2 dummy1 dummy2 zzz real0m0.040s user0m0.020s sys 0m0.030s // So, 'time' doesn't write to stderr (?!) Question-1. Where does the 'time' (shell keyword) write? Question-2. How to redirect output of the 'time' (shell keyword)? -- = Alex Vinokur mailto:[EMAIL PROTECTED] http://mathforum.org/library/view/10978.html news://news.gmane.org/gmane.comp.lang.c++.perfometer = -- 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/ -- You like to form new friendships and make new acquaintances. -- 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: VC++ and Perl
On Wed, Oct 15, 2003 at 11:46:27AM -0400, Paul Bezzam wrote: Hello all, I have a C program calling a Perl module running successfully under Cygwin. Can I use VC++ environment to call this Perl? Dunno and AFAICT it's off-topic here. If you want to do anything with MSVC, ask a MSVC-related newsgroup rlc -- Elliptic paraboloids for sale. -- 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: [forwarded email: cygwin mirrors and installation]
On Tue, Oct 07, 2003 at 05:35:24PM +1000, Robert Collins wrote: On Tue, 2003-10-07 at 13:02, Gary R. Van Sickle wrote: You'll have to forgive my ignorance here, but is there some way to query ftp/http servers for how much load they're under? Not as a standard. Thinking out loud, what we roughly want is: -users can choose any mirror explicitly. -on the first run, setup lists the servers in their 1/3 of the world (say europe, asia, americas) and randomly chooses one from there, ^^, africa, letting them alter the choice, or click something to see the entire list. -when we implement this, setup treats it as a watershed event on existing installs, and displays a little explanation and consider 'first run' to be occuring. Do we actually have information on where the different mirrors are? For all of them? Would it, as a temporary measure, be possible to randomize the mirror list for new installs so the first pick is not necesserilly the first alphabetical one? I think that would probably be a lot easier to implement than the final solution, and would help a little bit already.. Is there a way to know whether the user explicily chose their mirror (other than it not being the first in the list, and there only being one)? Just thinking.. rlc -- operators on strike due to broken coffee machine
Re: What Linux version corresponds to a specific cygwin version?
First: Cygwin != Linux On Tue, Oct 07, 2003 at 06:03:05PM +0200, Uwe Galle wrote: after some research this question remained unresolved, that's why I want to post it to the list. Some applications, e.g. C-Kermit 8.0 (http://www.columbia.edu/kermit/ck80binaries.html#linux), offer a variety of binary versions, e.g. Red Hat 7.0, Red Hat 7.1, 7.2, 7.3, 8.0, 9, AS2.1 and much more. The question is: What version I have to download for a certain cygwin version? If the package is part of the Cygwin Net Distribution, you can download it with http://cygwin.com/setup.exe. Please also read http://cygwin.com. uname shows for the latest cygwin version CYGWIN_NT-5.1. cygcheck -s shows as cygwin dll version 1.5.5. Are there any rules how to map this version information to a certain Linux version? Cygwin != Linux. Cygwin is a POSIX emulation layer for Windows. It is not based on Linux code, nor is it actually anything more than a DLL with many, many features. There is no way to map a Cygwin version number to a Linux version number because * there is no relation * the Cygwin version number (e.g. 1.5.5) is the number of the Cygwin DLL, not the distribution (comparable with Linux-2.4.x being the version number of the kernel). * there is no relation * there is no relation I think I cannot rely on the compatibility with the latest Red Hat version - also because of the fact that Red Hat doesn't offer only one version ... You're talking about *distribution* versions here - there is no versioning scheme for the Cygwin Net Distribution. rlc -- Statistics are no substitute for judgement. -- Henry Clay -- 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/
