Re: question (latest "stable" dll?) + bugs: vim, bash, gcc, cp, find, less, zip, ls

[Phil Edwards <pedwards@jaj.com>]

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