From: Phil Edwards <pedwards@jaj.com>
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 [thread overview]
Message-ID: <199906212309.TAA06508@jaj.com> (raw)
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
WARNING: multiple messages have this Message-ID
From: Phil Edwards <pedwards@jaj.com>
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 [thread overview]
Message-ID: <199906212309.TAA06508@jaj.com> (raw)
Message-ID: <19990630221000.iRexmwey2a7KrPmj2hh6YBvh1vMjjwdZvFW7dW4PMRk@z> (raw)
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
next reply other threads:[~1999-06-21 15:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-06-21 15:59 Phil Edwards [this message]
1999-06-21 16:32 ` Brendan Simon
1999-06-30 22:10 ` Brendan Simon
1999-06-22 11:00 ` itz
1999-06-30 22:10 ` itz
1999-06-30 22:10 ` Phil Edwards
-- strict thread matches above, loose matches on Subject: below --
1999-06-23 6:19 Lincoln, W. Terry
1999-06-30 22:10 ` Lincoln, W. Terry
1999-06-22 13:57 John Wiersba
1999-06-22 14:07 ` DJ Delorie
1999-06-30 22:10 ` DJ Delorie
1999-06-30 22:10 ` John Wiersba
1999-06-22 12:09 Lincoln, W. Terry
1999-06-30 22:10 ` Lincoln, W. Terry
1999-06-22 11:57 John Wiersba
1999-06-22 13:41 ` Christopher Faylor
1999-06-30 22:10 ` Christopher Faylor
1999-06-30 22:10 ` John Wiersba
1999-06-21 15:40 John Wiersba
1999-06-30 22:10 ` John Wiersba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199906212309.TAA06508@jaj.com \
--to=pedwards@jaj.com \
--cc=John.Wiersba@medstat.com \
--cc=cygwin@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).