From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phil Edwards To: cygwin@sourceware.cygnus.com, John.Wiersba@medstat.com Subject: Re: question (latest "stable" dll?) + bugs: vim, bash, gcc, cp, find, less, zip, ls Date: Mon, 21 Jun 1999 15:59:00 -0000 Message-id: <199906212309.TAA06508@jaj.com> X-SW-Source: 1999-06/msg00488.html I'll add/respond to the few that I've encountered. > 4) find is broken across mounts. find clearly can see the files/dirs under > the mount, but then for some reason, reports "No such file or directory". > See the bottom of this email for my cygcheck outout. > $ find / > / > /a > /a/a > find: /a/a/new.zip: No such file or directory > /bin > /c > find: /c/UNATTEND.TXT: No such file or directory > find: /c/BOOTSECT.DOS: No such file or directory > find: /c/WINNT: No such file or directory > find: /c/NTDETECT.COM: No such file or directory > find: /c/ntldr: No such file or directory > ... > /etc > /etc/group > /etc/hosts > ... I've had the same thing happen to me while trying to run updatedb. Nothing ever got written to the temp file, by the way, so if you were thinking of running locate/updatedb, don't. > 7) The version of gcc released in full.exe creates huge executables which > need to be stripped to come down to a reasonable size. The 1/15/99 gcc > fixes this (but not everyone will take the 1/15 release. The version of gcc released in full.exe is not what one would call recent, since full.exe is not that recent either. There's nothing the Cygwin folks can do about this one until the next Cygwin release, other than to recommend that the shipped compiler be replaced. Since Cygwin and EGCS are both experimental bleeding-edge packages, it's not too unreasonable to expect that people will be willing to try and replace certain packages. (Such replacement won't necessarily be /easy/, but that's also to be expected. :-) > 8) gcc doesn't use a very accomodating algorithm to find cpp. It appears > that if you do any rearranging of the originally installed directories, gcc Yeah, after you install it, the compiler directories are completely hands-off. I don't think that's such a terribly bad thing. There are some provisions made for altering those paths (the joy and pain of -B is something that I've just experienced), but it's not something that sould be treated as an everyday activity. :-) > 9) bash's internal "set" command doesn't appear to be interruptable with > cntl-c. Probably because the internal set command should never hang in the first place. If you're doing something to get bash to stop at a "set" then that's the bug that should probably be reported. I think. > 11) cp -p has an annoying behavior of (often, for me anyway) reporting a > permission problem when it fails to successfully chown the copied files. In > fact, the files do get set to the proper owner. I had to fix this by > commenting out the error handling starting at lines 983-986 of cp.c so that > if a chown error occurs, it's ignored. I had similar problems with chown(1) itself, and I /think/ the cause is a mismatched binary / cygwin1.dll combination, so that chown(2) gets some freaky results. The command would work correctly, but the return code would be funky. This would then cause a parent make(1) to exit, etc, etc. (If you reply to the list, please don't cc another copy to me. Thanks!) Phil -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phil Edwards To: cygwin@sourceware.cygnus.com, John.Wiersba@medstat.com Subject: Re: question (latest "stable" dll?) + bugs: vim, bash, gcc, cp, find, less, zip, ls Date: Wed, 30 Jun 1999 22:10:00 -0000 Message-ID: <199906212309.TAA06508@jaj.com> X-SW-Source: 1999-06n/msg00488.html Message-ID: <19990630221000.iRexmwey2a7KrPmj2hh6YBvh1vMjjwdZvFW7dW4PMRk@z> I'll add/respond to the few that I've encountered. > 4) find is broken across mounts. find clearly can see the files/dirs under > the mount, but then for some reason, reports "No such file or directory". > See the bottom of this email for my cygcheck outout. > $ find / > / > /a > /a/a > find: /a/a/new.zip: No such file or directory > /bin > /c > find: /c/UNATTEND.TXT: No such file or directory > find: /c/BOOTSECT.DOS: No such file or directory > find: /c/WINNT: No such file or directory > find: /c/NTDETECT.COM: No such file or directory > find: /c/ntldr: No such file or directory > ... > /etc > /etc/group > /etc/hosts > ... I've had the same thing happen to me while trying to run updatedb. Nothing ever got written to the temp file, by the way, so if you were thinking of running locate/updatedb, don't. > 7) The version of gcc released in full.exe creates huge executables which > need to be stripped to come down to a reasonable size. The 1/15/99 gcc > fixes this (but not everyone will take the 1/15 release. The version of gcc released in full.exe is not what one would call recent, since full.exe is not that recent either. There's nothing the Cygwin folks can do about this one until the next Cygwin release, other than to recommend that the shipped compiler be replaced. Since Cygwin and EGCS are both experimental bleeding-edge packages, it's not too unreasonable to expect that people will be willing to try and replace certain packages. (Such replacement won't necessarily be /easy/, but that's also to be expected. :-) > 8) gcc doesn't use a very accomodating algorithm to find cpp. It appears > that if you do any rearranging of the originally installed directories, gcc Yeah, after you install it, the compiler directories are completely hands-off. I don't think that's such a terribly bad thing. There are some provisions made for altering those paths (the joy and pain of -B is something that I've just experienced), but it's not something that sould be treated as an everyday activity. :-) > 9) bash's internal "set" command doesn't appear to be interruptable with > cntl-c. Probably because the internal set command should never hang in the first place. If you're doing something to get bash to stop at a "set" then that's the bug that should probably be reported. I think. > 11) cp -p has an annoying behavior of (often, for me anyway) reporting a > permission problem when it fails to successfully chown the copied files. In > fact, the files do get set to the proper owner. I had to fix this by > commenting out the error handling starting at lines 983-986 of cp.c so that > if a chown error occurs, it's ignored. I had similar problems with chown(1) itself, and I /think/ the cause is a mismatched binary / cygwin1.dll combination, so that chown(2) gets some freaky results. The command would work correctly, but the return code would be funky. This would then cause a parent make(1) to exit, etc, etc. (If you reply to the list, please don't cc another copy to me. Thanks!) Phil -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com