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

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

[Lincoln, W. Terry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

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





> -----Original Message-----
> From: itz@lbin.com [ mailto:itz@lbin.com ]
> Sent: Tuesday, June 22, 1999 1:59 PM
> To: pedwards@jaj.com
> Cc: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
>    Mailing-List: contact cygwin-help@sourceware.cygnus.com; 
> run by ezmlm
>    Precedence: bulk
>    Sender: cygwin-owner@sourceware.cygnus.com
>    Delivered-To: mailing list cygwin@sourceware.cygnus.com
>    Date: Mon, 21 Jun 1999 19:09:05 -0400
>    From: 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
   -- Snip --
> 
>    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.
> 
> There's a workaround for updatedb: use the --netpaths option.  For
> instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
> well.
> 
> But both these problems are symptoms of a bug in the path translation
> layer that was only addressed on March 28.  A simpler way to
> demonstrate the problem is just to create a mount point and try to
> access a file below it with a relative path.  A real killer bug IMHO
> but MHO doesn't count :-)


I am afraid I too agree that this is pretty much a utility killer of a bug.  Perhaps this will someday be addressed and a real solution will be put forth.  This BUG has crippled many of my out-of-box porting attempts. :-(

> 
> -- 
> Ian Zimmerman
> Lightbinders, Inc.
> 2325 3rd Street #324
> San Francisco, California 94107
> U.S.A.
> 


W. Terry Lincoln                         \     \   _   /
Senior Engineer                           \     \ |J| /
Ultimate Technology Corporation            \    __|E|__
a Tridex Company (NASDAQ:trdx)              \  |__ S __|
mailto:WTerryLincoln@engineer.com             \    |U|
http://www.AngelFire.com/ny/TerryLincoln       \ / |S| \
http://www.geocities.com/Eureka/concourse/7326 \  | |
ICQ #39362285                                   \ | |
================================================ ~~~~~
Opinions expressed do not represent the management of UTC.


 


Warren Terry Lincoln (E-mail).vcf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Chris Faylor]

On Tue, Jun 22, 1999 at 02:55:41PM -0400, Lincoln, W. Terry wrote:
>> From: itz@lbin.com [ mailto:itz@lbin.com ]
>> But both these problems are symptoms of a bug in the path translation
>> layer that was only addressed on March 28.  A simpler way to
>> demonstrate the problem is just to create a mount point and try to
>> access a file below it with a relative path.  A real killer bug IMHO
>> but MHO doesn't count :-)
>
>I am afraid I too agree that this is pretty much a utility killer of a bug.
>Perhaps this will someday be addressed and a real solution will be put
>forth.  This BUG has crippled many of my out-of-box porting attempts. :-(

Did you read the part that said "was... addressed on March 28"?  What kind
of "real solution" were you looking for besides a change to the DLL which
fixes the problem?

Incidentally, this terrible, unbelievably crippling bug has been in cygwin
pretty much since the beginning.

Also, I could be wrong, but I believe that this is also solved by creating
the appropriate directories in your root, as is suggested when you use the
mount program.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Chris Faylor]

On Tue, Jun 22, 1999 at 02:55:41PM -0400, Lincoln, W. Terry wrote:
>> From: itz@lbin.com [ mailto:itz@lbin.com ]
>> But both these problems are symptoms of a bug in the path translation
>> layer that was only addressed on March 28.  A simpler way to
>> demonstrate the problem is just to create a mount point and try to
>> access a file below it with a relative path.  A real killer bug IMHO
>> but MHO doesn't count :-)
>
>I am afraid I too agree that this is pretty much a utility killer of a bug.
>Perhaps this will someday be addressed and a real solution will be put
>forth.  This BUG has crippled many of my out-of-box porting attempts. :-(

Did you read the part that said "was... addressed on March 28"?  What kind
of "real solution" were you looking for besides a change to the DLL which
fixes the problem?

Incidentally, this terrible, unbelievably crippling bug has been in cygwin
pretty much since the beginning.

Also, I could be wrong, but I believe that this is also solved by creating
the appropriate directories in your root, as is suggested when you use the
mount program.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Lincoln, W. Terry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

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





> -----Original Message-----
> From: itz@lbin.com [ mailto:itz@lbin.com ]
> Sent: Tuesday, June 22, 1999 1:59 PM
> To: pedwards@jaj.com
> Cc: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
>    Mailing-List: contact cygwin-help@sourceware.cygnus.com; 
> run by ezmlm
>    Precedence: bulk
>    Sender: cygwin-owner@sourceware.cygnus.com
>    Delivered-To: mailing list cygwin@sourceware.cygnus.com
>    Date: Mon, 21 Jun 1999 19:09:05 -0400
>    From: 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
   -- Snip --
> 
>    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.
> 
> There's a workaround for updatedb: use the --netpaths option.  For
> instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
> well.
> 
> But both these problems are symptoms of a bug in the path translation
> layer that was only addressed on March 28.  A simpler way to
> demonstrate the problem is just to create a mount point and try to
> access a file below it with a relative path.  A real killer bug IMHO
> but MHO doesn't count :-)


I am afraid I too agree that this is pretty much a utility killer of a bug.  Perhaps this will someday be addressed and a real solution will be put forth.  This BUG has crippled many of my out-of-box porting attempts. :-(

> 
> -- 
> Ian Zimmerman
> Lightbinders, Inc.
> 2325 3rd Street #324
> San Francisco, California 94107
> U.S.A.
> 


W. Terry Lincoln                         \     \   _   /
Senior Engineer                           \     \ |J| /
Ultimate Technology Corporation            \    __|E|__
a Tridex Company (NASDAQ:trdx)              \  |__ S __|
mailto:WTerryLincoln@engineer.com             \    |U|
http://www.AngelFire.com/ny/TerryLincoln       \ / |S| \
http://www.geocities.com/Eureka/concourse/7326 \  | |
ICQ #39362285                                   \ | |
================================================ ~~~~~
Opinions expressed do not represent the management of UTC.


 


Warren Terry Lincoln (E-mail).vcf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


[-- Attachment #2: Warren_Terry_Lincoln_(E-mail).vcf --]
[-- Type: text/vcard, Size: 725 bytes --]

BEGIN:VCARD
VERSION:2.1
N:Lincoln;Warren;;Mr.;
FN:Warren Terry Lincoln (E-mail)
ORG:UTC;Engineering
TITLE:Senior Engineer
TEL;WORK;VOICE:(716) 924-9500
TEL;HOME;VOICE:(716) 377-3959
TEL;CELL;VOICE:(716) 261-3959
TEL;CAR;VOICE:
TEL;WORK;FAX:(716) 924-1434
ADR;WORK:;Victor;100 Rawson Road;Victor;NY;14564-0000;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Victor=0D=0A100 Rawson Road=0D=0AVictor, NY 14564-0000=0D=0AUnited States of=
 America
ADR;HOME:;;100 Courtshire Lane;Penfield;NY;10526-2678;United States of America
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:100 Courtshire Lane=0D=0APenfield, NY 10526-2678=0D=0AUnited States of Ameri=
ca
EMAIL;PREF;MS:ULTIMATE/UTCPO/LincolnT
REV:19990121T133603Z
END:VCARD

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

[John Wiersba]

Christopher,

I took my cygwin1.dll from ftp://sourceware.cygnus.com/pub/cygwin/snapshots/
which doesn't show any mount.exe.  I was looking for the dll closest in date
to the 3/28 date mentioned in the referenced email.  So, after I exited all
cygwin processes and switched in the 5/23 cygwin1.dll and restarted a bash
shell, my mounts were screwed up.  I couldn't even find mount.exe because my
cygwin directory wasn't mounted (i.e. / wasn't mounted properly).  After
some amount of playing around in the registry, I got my cygwin directory
mounted properly, so from that point on I was able to use the old (i.e.
1/16) version of mount to remount my other directories.  If I read your
email correctly, you're saying that there is a newer version of mount.exe
which I could use.  For obvious reasons, I didn't want to download/install
cygwin-inst-XXX (where the new mount.exe is located?) until I had verified
that cygwin1.dll worked ok.  

Eventually, I'll probably unpack the bash source and see if I can diagnose
the "cd /; cd x/y" bug.  I agree it does sound like a bash bug.  For now I
have an ugly work around: I defined a bash function which hooks the cd
command and checks if I'm in the root and referencing a relative path which
exists under the root (knowing that . is the first entry in my CDPATH) and
prepends a / to the path before calling the real cd command.

-- John

> -----Original Message-----
> From: Christopher Faylor [ mailto:cygwin@sourceware.cygnus.com ]
> Sent: Tuesday, June 22, 1999 4:42 PM
> To: John Wiersba
> Cc: 'cygwin@sourceware.cygnus.com'
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
> On Tue, Jun 22, 1999 at 02:56:38PM -0400, John Wiersba wrote:
> >Since no one has yet suggested a "stable" release of 
> cygwin1.dll after 1/16,
> >I tried the 5/23 release (it was the earliest one I could 
> find after the
> >3/28 date mentioned below).  It seems to be relatively 
> stable so far (i.e.
> >I've used it for several minutes so far!).  I did have to twiddle the
> >registry settings for mounts (not unexpected, after the 
> comment about mounts
> >below).
> 
> What does "twiddle the registry settings" mean, exactly?  
> Does that mean that
> you didn't use the newer "mount" program which is associated 
> with the DLL?
> 
> AFAIK, there should be no need for any manual invervention in 
> switching from
> an older DLL to a newer.  The new DLL should read the older 
> mount settings
> and copy them to the appropriate place in the registry.
> 
> >2) It does not however seem to fix the "cd /; cd 
> relativepath/dir" problem
> >(apparently going out to the LAN).  Note that cd does 
> eventually work -- it
> >just hangs for several seconds before figuring things out. 
> >
> >=> Additional information: it doesn't hang when CDPATH is 
> unset.  It does
> >hang when CDPATH=.
> 
> So, in other words, this is probably  bash bug.  Is anyone 
> willing to debug
> this and offer a fix?
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Christopher Faylor]

On Tue, Jun 22, 1999 at 02:56:38PM -0400, John Wiersba wrote:
>Since no one has yet suggested a "stable" release of cygwin1.dll after 1/16,
>I tried the 5/23 release (it was the earliest one I could find after the
>3/28 date mentioned below).  It seems to be relatively stable so far (i.e.
>I've used it for several minutes so far!).  I did have to twiddle the
>registry settings for mounts (not unexpected, after the comment about mounts
>below).

What does "twiddle the registry settings" mean, exactly?  Does that mean that
you didn't use the newer "mount" program which is associated with the DLL?

AFAIK, there should be no need for any manual invervention in switching from
an older DLL to a newer.  The new DLL should read the older mount settings
and copy them to the appropriate place in the registry.

>2) It does not however seem to fix the "cd /; cd relativepath/dir" problem
>(apparently going out to the LAN).  Note that cd does eventually work -- it
>just hangs for several seconds before figuring things out. 
>
>=> Additional information: it doesn't hang when CDPATH is unset.  It does
>hang when CDPATH=.

So, in other words, this is probably  bash bug.  Is anyone willing to debug
this and offer a fix?

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[DJ Delorie]

> For obvious reasons, I didn't want to download/install
> cygwin-inst-XXX (where the new mount.exe is located?)

Yes, that's where mount.exe is.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Phil Edwards]

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

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

[John Wiersba]

Since no one has yet suggested a "stable" release of cygwin1.dll after 1/16,
I tried the 5/23 release (it was the earliest one I could find after the
3/28 date mentioned below).  It seems to be relatively stable so far (i.e.
I've used it for several minutes so far!).  I did have to twiddle the
registry settings for mounts (not unexpected, after the comment about mounts
below).

1) It fixed the "find is broken across mounts" and "running a program using
a relative path" problems I mentioned yesterday.  

2) It does not however seem to fix the "cd /; cd relativepath/dir" problem
(apparently going out to the LAN).  Note that cd does eventually work -- it
just hangs for several seconds before figuring things out. 

=> Additional information: it doesn't hang when CDPATH is unset.  It does
hang when CDPATH=.

3) It "semi-fixed" the vim/TERM=linux bug I reported yesterday.  Now, if I
hit backspace several times, vim still locks up, but a cntl-c gets vim's
attention so that the editing session can be resumed.  This is still bad
enough that I consider vim/TERM=linux unusable, but it's an improvement!

-- John Wiersba (john.wiersba@medstat.com)

> -----Original Message-----
> From: itz@lbin.com [ mailto:itz@lbin.com ]
> Sent: Tuesday, June 22, 1999 1:59 PM
> To: pedwards@jaj.com
> Cc: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
>    Mailing-List: contact cygwin-help@sourceware.cygnus.com; 
> run by ezmlm
>    Precedence: bulk
>    Sender: cygwin-owner@sourceware.cygnus.com
>    Delivered-To: mailing list cygwin@sourceware.cygnus.com
>    Date: Mon, 21 Jun 1999 19:09:05 -0400
>    From: 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.
> 
> There's a workaround for updatedb: use the --netpaths option.  For
> instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
> well.
> 
> But both these problems are symptoms of a bug in the path translation
> layer that was only addressed on March 28.  A simpler way to
> demonstrate the problem is just to create a mount point and try to
> access a file below it with a relative path.  A real killer bug IMHO
> but MHO doesn't count :-)
> 
> -- 
> Ian Zimmerman
> Lightbinders, Inc.
> 2325 3rd Street #324
> San Francisco, California 94107
> U.S.A.
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Lincoln, W. Terry]

> -----Original Message-----
> From: Chris Faylor [ mailto:cgf@cygnus.com ]
> Sent: Tuesday, June 22, 1999 4:37 PM
> To: WTerryLincoln@engineer.com
> 
> 
> On Tue, Jun 22, 1999 at 02:55:41PM -0400, Lincoln, W. Terry wrote:
> >> From: itz@lbin.com [ mailto:itz@lbin.com ]
> >> But both these problems are symptoms of a bug in the path 
> translation
> >> layer that was only addressed on March 28.  A simpler way to
> >> demonstrate the problem is just to create a mount point and try to
> >> access a file below it with a relative path.  A real 
> killer bug IMHO
> >> but MHO doesn't count :-)
> >
> >I am afraid I too agree that this is pretty much a utility 
> killer of a bug.
> >Perhaps this will someday be addressed and a real solution 
> will be put
> >forth.  This BUG has crippled many of my out-of-box porting 
> attempts. :-(
> 
> Did you read the part that said "was... addressed on March 
> 28"?  What kind
> of "real solution" were you looking for besides a change to 
> the DLL which
> fixes the problem?

Sorry Chris,

I have been somewhat reluctant to download and install some of these newer
releases because while a few bugs have been addressed and fixed, I have been
reading about other semi-crippling bugs being introduced.

I have been looking for announcements in this list of significant fixes such
as you mention, but perhaps I lost some mail that did that.

Since I have not been fully apprised of which bugs have been backed out I
haven't bothered to change.  Also, since the last DLL I have has been the
most stable _for me_, I didn't install the March 28 version *yet* ;-)

I guess that I will have to update again and hope for increased
functionality (at the expense of changing share
> 
> Incidentally, this terrible, unbelievably crippling bug has 
> been in cygwin
> pretty much since the beginning.
> 
> Also, I could be wrong, but I believe that this is also 
> solved by creating
> the appropriate directories in your root, as is suggested 
> when you use the
> mount program.
> 
> cgf
> 

W. Terry Lincoln - Senior Engineer         \     \   _   /
Ultimate Technology Corporation             \     \ |J| /
a Tridex Company (NASDAQ:trdx)               \     _|E|_
ICQ < http://wwp.icq.com/39362285 >             \   |_ S _|
Email: < mailto:WTerryLincoln@engineer.com >     \    |U|
< http://www.AngelFire.com/ny/TerryLincoln >      \ / |S| \
< http://www.geocities.com/Eureka/Concourse/7326 > \  | |
================================================== ~~~~~
Opinions expressed do not represent the management of UTC.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[itz]

   Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
   Precedence: bulk
   Sender: cygwin-owner@sourceware.cygnus.com
   Delivered-To: mailing list cygwin@sourceware.cygnus.com
   Date: Mon, 21 Jun 1999 19:09:05 -0400
   From: 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.

There's a workaround for updatedb: use the --netpaths option.  For
instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
well.

But both these problems are symptoms of a bug in the path translation
layer that was only addressed on March 28.  A simpler way to
demonstrate the problem is just to create a mount point and try to
access a file below it with a relative path.  A real killer bug IMHO
but MHO doesn't count :-)

-- 
Ian Zimmerman
Lightbinders, Inc.
2325 3rd Street #324
San Francisco, California 94107
U.S.A.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Brendan Simon]

Phil Edwards wrote:

> 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.  :-)

You can get the LATEST port of gcc for cygwin32, mingw32 and UWIN from Mumit
Khan's web/ftp site.
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
These are drop in replacements for the cygwin32, mingw32 and UWIN pacages.

Brendan Simon.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[John Wiersba]

Question:

Is there a later "stable" release than 19990115?  I installed
cygwin-inst-19990115.tar.gz (which actually has a date of 1/16/99), but
there are a few significant bugs (see below) that I'd like to get fixes to
if possible.  I tried downloading a recent cygwin1.dll, but it was obviously
not meant for general consumption since it dumped some sort of trace to the
screen when it ran.

--------------------
Bugs reports.

I'm submitting all these in one lump, since I don't want to fill up the
mailing list with too much mail.  I realize that it will make the subject
line less useful to bunch these up.

1) Running programs using relative paths is screwed up.  I've seen mention
of this bug in the archives, so I know it's not new.  Is there a more recent
"stable" cygwin1.dll which fixes this?

2) Every once in a while one or more of my terminals gets into a mode where
I can't cntl-c out of (any?) program run from that terminal.  I just have to
let the program finish.  This can be quite annoying if I was running
something like find /.  The general fix seems to be to unload cygwin1.dll by
exiting all bash sessions, which is obviously less than optimal.

3) The following two commands cause bash to hang for several seconds before
executing properly.  I believe that bash is, for some reason, going out to
the LAN before figuring out what to do.  Could it be related to bug #1?
   cd /
   cd relativepath/subdir
Other symptoms:  after experiencing this bug, an immediate retry of these
two commands will usually work speedily (which is why I believe that it is
related to something cached on the network), but waiting a little longer
causes a replay of the original several-second hang.

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
      ...

5) vim 5.3 is badly broken using TERM=linux.  After starting it, if I hit
backspace once or twice quickly, it hangs in an infinite loop.  Sending it a
signal from another shell prompt causes it to report:
   Vim: Caught deadly signal TERM
   Vim: Finished.
after which the shell is hosed (because vim didn't reset it when it exited).
Trying TERM=ansi works ok except that the function keys aren't defined.
TERM=xterm works for function keys 5-8, but not 1-4.  I eventually made my
own terminal definition based on xterm which properly defines function keys
1-4, too.  Could it be that I'm the only one using vim which has this
problem (I didn't see it in the archives)?

6) I can't get less to take into account that wrapped lines take up multiple
screen lines.  This has the annoying side effect of scrolling the top few
lines off the screen.  The only workaround I've found is to use fold -w79 |
less.

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.

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
gets totally lost and requires that GCC_EXEC_PREFIX be defined.  It would be
nice for gcc to try a few other likely places before giving up.  For
example, gcc might try ../lib/gcc-lib relative to the directory where gcc is
found.  Also, I couldn't find any documentation about what value to use for
GCC_EXEC_PREFIX.  It's not obvious that it should be set to cpp's parent's
parent's directory.

9) bash's internal "set" command doesn't appear to be interruptable with
cntl-c.  

10) zip (built according to the directions at ftp.franken.de) fails when
redirecting output to a UNC path, e.g. 
   zip -r - . >//h/mystuff.zip
reporting:
   zip error: Internal logic error (incorrect compressed size)

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 think that silently ignoring such
errors when called with the -p option is a more proper behavior, because
there doesn't seem to be a good reason to squawk when the file has been
successfully copied and it's only the file ownership which can't be set
correctly.

12) Under cygwin 19, "ls -lF /" didn't need to hit my floppy drive, even
though a: was mounted as /a.  But under cygwin 20 it does, forcing me to use
something less intuitive than /a (so that whenever I don't have to wait
while the floppy disk grinds whenever I get a listing of /).

Output of cygcheck -s -r -v:

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Mon Jun 21 18:05:14 1999

WinNT Ver 4.0 build 1381 Service Pack 4

Path:	/jrw/jrw/mdst/sh
	/jrw/binu
	/opt/cygwin/local/bin
	/opt/cygwin/bin
	/opt/cygwin/bin
	/jrw/binw
	/winnt/system32
	/winnt
	.

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

CYGWIN = `  notitle tty nostrip_title binmode glob'
GCC_EXEC_PREFIX = `/opt/cygwin/lib/gcc-lib/'
HOME = `/jrw'
MAKE_MODE = `UNIX'
PWD = `/jrw/jrw/mdst/mab'

...<snip>...
CDPATH = `.:..:/jrw'
COLUMNS = `80'
LINES = `67'
...<snip>...

HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `C:'
  unix = `/c'
  fbinary = 0x00000001
  fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
  (default) = `A:'
  unix = `/a/a'
  fbinary = 0x00000001
  fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
  (default) = `D:'
  unix = `/'
  fbinary = 0x00000001
  fsilent = 0x00000001
HKEY_CURRENT_USER\Software\FTP Explorer\Profiles\cygnus
  (default) = `sourceware.cygnus.com'
  Login = `anonymous'
  InitialPath = `/pub/cygwin'
  AnonLogin = 0x00000001
  CacheData = 0x00000000
  Description = `'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
...<snip>...
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
  (default) = `d:\opt\cygwin\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnu
s Cygwin B20
  (default) = `C:\WINNT\IsUninst.exe -fd:\opt\cygwin\cygwin-b20\Uninst.isu'
  DisplayName = `Cygwin B20'

a:\ fd  FAT        1Mb  39% CP    UN           
c:\ hd  FAT     2044Mb  29% CP    UN           
d:\ hd  NTFS    4104Mb  26% CP CS UN PA FC     
e:\ cd           N/A    N/A                    
f:\ net NWFS     900Mb  39% CP                 SYS
...<snip>...

D:    /        native  text=binary
A:    /a/a     native  text=binary
C:    /c       native  text=binary

Found: D:\opt\cygwin\bin\bash.exe
Found: D:\opt\cygwin\bin\cat.exe
Not Found: cpp (good!)
Found: D:\opt\cygwin\bin\find.exe
Found: D:\opt\cygwin\bin\gcc.exe
Found: D:\opt\cygwin\bin\gdb.exe
Found: D:\opt\cygwin\bin\ld.exe
Found: D:\opt\cygwin\bin\ls.exe
Found: D:\opt\cygwin\bin\make.exe
Found: D:\opt\cygwin\bin\sh.exe

  371k 1998/12/01 D:\opt\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=1998/12/1 3:25
    5k 1998/12/01 D:\opt\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 1998/12/01 D:\opt\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
  600k 1998/12/01 D:\opt\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=1998/12/1 3:28
  446k 1998/12/04 D:\opt\cygwin\bin\cygwin1-old.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=1998/12/3 23:39
  451k 1999/06/15 D:\opt\cygwin\bin\cygwin1-recommended.dll - os=4.0 img=1.0
sys=4.0
                  "cygwin1.dll" v0.0 ts=1999/1/16 0:09
  451k 1999/01/16 D:\opt\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=1999/1/16 0:09

Anyway, even with these problems, cygwin is a life-saver for someone having
to work in a windows environment.  It's amazing that it's so usable!  Thanks
guys!

John Wiersba (john.wiersba@medstat.com)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Lincoln, W. Terry]

> -----Original Message-----
> From: Chris Faylor [ mailto:cgf@cygnus.com ]
> Sent: Tuesday, June 22, 1999 4:37 PM
> To: WTerryLincoln@engineer.com
> 
> 
> On Tue, Jun 22, 1999 at 02:55:41PM -0400, Lincoln, W. Terry wrote:
> >> From: itz@lbin.com [ mailto:itz@lbin.com ]
> >> But both these problems are symptoms of a bug in the path 
> translation
> >> layer that was only addressed on March 28.  A simpler way to
> >> demonstrate the problem is just to create a mount point and try to
> >> access a file below it with a relative path.  A real 
> killer bug IMHO
> >> but MHO doesn't count :-)
> >
> >I am afraid I too agree that this is pretty much a utility 
> killer of a bug.
> >Perhaps this will someday be addressed and a real solution 
> will be put
> >forth.  This BUG has crippled many of my out-of-box porting 
> attempts. :-(
> 
> Did you read the part that said "was... addressed on March 
> 28"?  What kind
> of "real solution" were you looking for besides a change to 
> the DLL which
> fixes the problem?

Sorry Chris,

I have been somewhat reluctant to download and install some of these newer
releases because while a few bugs have been addressed and fixed, I have been
reading about other semi-crippling bugs being introduced.

I have been looking for announcements in this list of significant fixes such
as you mention, but perhaps I lost some mail that did that.

Since I have not been fully apprised of which bugs have been backed out I
haven't bothered to change.  Also, since the last DLL I have has been the
most stable _for me_, I didn't install the March 28 version *yet* ;-)

I guess that I will have to update again and hope for increased
functionality (at the expense of changing share
> 
> Incidentally, this terrible, unbelievably crippling bug has 
> been in cygwin
> pretty much since the beginning.
> 
> Also, I could be wrong, but I believe that this is also 
> solved by creating
> the appropriate directories in your root, as is suggested 
> when you use the
> mount program.
> 
> cgf
> 

W. Terry Lincoln - Senior Engineer         \     \   _   /
Ultimate Technology Corporation             \     \ |J| /
a Tridex Company (NASDAQ:trdx)               \     _|E|_
ICQ < http://wwp.icq.com/39362285 >             \   |_ S _|
Email: < mailto:WTerryLincoln@engineer.com >     \    |U|
< http://www.AngelFire.com/ny/TerryLincoln >      \ / |S| \
< http://www.geocities.com/Eureka/Concourse/7326 > \  | |
================================================== ~~~~~
Opinions expressed do not represent the management of UTC.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[DJ Delorie]

> For obvious reasons, I didn't want to download/install
> cygwin-inst-XXX (where the new mount.exe is located?)

Yes, that's where mount.exe is.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[John Wiersba]

Christopher,

I took my cygwin1.dll from ftp://sourceware.cygnus.com/pub/cygwin/snapshots/
which doesn't show any mount.exe.  I was looking for the dll closest in date
to the 3/28 date mentioned in the referenced email.  So, after I exited all
cygwin processes and switched in the 5/23 cygwin1.dll and restarted a bash
shell, my mounts were screwed up.  I couldn't even find mount.exe because my
cygwin directory wasn't mounted (i.e. / wasn't mounted properly).  After
some amount of playing around in the registry, I got my cygwin directory
mounted properly, so from that point on I was able to use the old (i.e.
1/16) version of mount to remount my other directories.  If I read your
email correctly, you're saying that there is a newer version of mount.exe
which I could use.  For obvious reasons, I didn't want to download/install
cygwin-inst-XXX (where the new mount.exe is located?) until I had verified
that cygwin1.dll worked ok.  

Eventually, I'll probably unpack the bash source and see if I can diagnose
the "cd /; cd x/y" bug.  I agree it does sound like a bash bug.  For now I
have an ugly work around: I defined a bash function which hooks the cd
command and checks if I'm in the root and referencing a relative path which
exists under the root (knowing that . is the first entry in my CDPATH) and
prepends a / to the path before calling the real cd command.

-- John

> -----Original Message-----
> From: Christopher Faylor [ mailto:cygwin@sourceware.cygnus.com ]
> Sent: Tuesday, June 22, 1999 4:42 PM
> To: John Wiersba
> Cc: 'cygwin@sourceware.cygnus.com'
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
> On Tue, Jun 22, 1999 at 02:56:38PM -0400, John Wiersba wrote:
> >Since no one has yet suggested a "stable" release of 
> cygwin1.dll after 1/16,
> >I tried the 5/23 release (it was the earliest one I could 
> find after the
> >3/28 date mentioned below).  It seems to be relatively 
> stable so far (i.e.
> >I've used it for several minutes so far!).  I did have to twiddle the
> >registry settings for mounts (not unexpected, after the 
> comment about mounts
> >below).
> 
> What does "twiddle the registry settings" mean, exactly?  
> Does that mean that
> you didn't use the newer "mount" program which is associated 
> with the DLL?
> 
> AFAIK, there should be no need for any manual invervention in 
> switching from
> an older DLL to a newer.  The new DLL should read the older 
> mount settings
> and copy them to the appropriate place in the registry.
> 
> >2) It does not however seem to fix the "cd /; cd 
> relativepath/dir" problem
> >(apparently going out to the LAN).  Note that cd does 
> eventually work -- it
> >just hangs for several seconds before figuring things out. 
> >
> >=> Additional information: it doesn't hang when CDPATH is 
> unset.  It does
> >hang when CDPATH=.
> 
> So, in other words, this is probably  bash bug.  Is anyone 
> willing to debug
> this and offer a fix?
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Christopher Faylor]

On Tue, Jun 22, 1999 at 02:56:38PM -0400, John Wiersba wrote:
>Since no one has yet suggested a "stable" release of cygwin1.dll after 1/16,
>I tried the 5/23 release (it was the earliest one I could find after the
>3/28 date mentioned below).  It seems to be relatively stable so far (i.e.
>I've used it for several minutes so far!).  I did have to twiddle the
>registry settings for mounts (not unexpected, after the comment about mounts
>below).

What does "twiddle the registry settings" mean, exactly?  Does that mean that
you didn't use the newer "mount" program which is associated with the DLL?

AFAIK, there should be no need for any manual invervention in switching from
an older DLL to a newer.  The new DLL should read the older mount settings
and copy them to the appropriate place in the registry.

>2) It does not however seem to fix the "cd /; cd relativepath/dir" problem
>(apparently going out to the LAN).  Note that cd does eventually work -- it
>just hangs for several seconds before figuring things out. 
>
>=> Additional information: it doesn't hang when CDPATH is unset.  It does
>hang when CDPATH=.

So, in other words, this is probably  bash bug.  Is anyone willing to debug
this and offer a fix?

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[John Wiersba]

Since no one has yet suggested a "stable" release of cygwin1.dll after 1/16,
I tried the 5/23 release (it was the earliest one I could find after the
3/28 date mentioned below).  It seems to be relatively stable so far (i.e.
I've used it for several minutes so far!).  I did have to twiddle the
registry settings for mounts (not unexpected, after the comment about mounts
below).

1) It fixed the "find is broken across mounts" and "running a program using
a relative path" problems I mentioned yesterday.  

2) It does not however seem to fix the "cd /; cd relativepath/dir" problem
(apparently going out to the LAN).  Note that cd does eventually work -- it
just hangs for several seconds before figuring things out. 

=> Additional information: it doesn't hang when CDPATH is unset.  It does
hang when CDPATH=.

3) It "semi-fixed" the vim/TERM=linux bug I reported yesterday.  Now, if I
hit backspace several times, vim still locks up, but a cntl-c gets vim's
attention so that the editing session can be resumed.  This is still bad
enough that I consider vim/TERM=linux unusable, but it's an improvement!

-- John Wiersba (john.wiersba@medstat.com)

> -----Original Message-----
> From: itz@lbin.com [ mailto:itz@lbin.com ]
> Sent: Tuesday, June 22, 1999 1:59 PM
> To: pedwards@jaj.com
> Cc: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: Re: question (latest "stable" dll?) + bugs: vim, 
> bash, gcc, cp,
> find, less, zip, ls
> 
> 
>    Mailing-List: contact cygwin-help@sourceware.cygnus.com; 
> run by ezmlm
>    Precedence: bulk
>    Sender: cygwin-owner@sourceware.cygnus.com
>    Delivered-To: mailing list cygwin@sourceware.cygnus.com
>    Date: Mon, 21 Jun 1999 19:09:05 -0400
>    From: 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.
> 
> There's a workaround for updatedb: use the --netpaths option.  For
> instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
> well.
> 
> But both these problems are symptoms of a bug in the path translation
> layer that was only addressed on March 28.  A simpler way to
> demonstrate the problem is just to create a mount point and try to
> access a file below it with a relative path.  A real killer bug IMHO
> but MHO doesn't count :-)
> 
> -- 
> Ian Zimmerman
> Lightbinders, Inc.
> 2325 3rd Street #324
> San Francisco, California 94107
> U.S.A.
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[itz]

   Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
   Precedence: bulk
   Sender: cygwin-owner@sourceware.cygnus.com
   Delivered-To: mailing list cygwin@sourceware.cygnus.com
   Date: Mon, 21 Jun 1999 19:09:05 -0400
   From: 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.

There's a workaround for updatedb: use the --netpaths option.  For
instance, updatedb --netpaths=//d/.  You'll probably need --netuser as
well.

But both these problems are symptoms of a bug in the path translation
layer that was only addressed on March 28.  A simpler way to
demonstrate the problem is just to create a mount point and try to
access a file below it with a relative path.  A real killer bug IMHO
but MHO doesn't count :-)

-- 
Ian Zimmerman
Lightbinders, Inc.
2325 3rd Street #324
San Francisco, California 94107
U.S.A.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Brendan Simon]

Phil Edwards wrote:

> 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.  :-)

You can get the LATEST port of gcc for cygwin32, mingw32 and UWIN from Mumit
Khan's web/ftp site.
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
These are drop in replacements for the cygwin32, mingw32 and UWIN pacages.

Brendan Simon.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Phil Edwards]

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

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

[John Wiersba]

Question:

Is there a later "stable" release than 19990115?  I installed
cygwin-inst-19990115.tar.gz (which actually has a date of 1/16/99), but
there are a few significant bugs (see below) that I'd like to get fixes to
if possible.  I tried downloading a recent cygwin1.dll, but it was obviously
not meant for general consumption since it dumped some sort of trace to the
screen when it ran.

--------------------
Bugs reports.

I'm submitting all these in one lump, since I don't want to fill up the
mailing list with too much mail.  I realize that it will make the subject
line less useful to bunch these up.

1) Running programs using relative paths is screwed up.  I've seen mention
of this bug in the archives, so I know it's not new.  Is there a more recent
"stable" cygwin1.dll which fixes this?

2) Every once in a while one or more of my terminals gets into a mode where
I can't cntl-c out of (any?) program run from that terminal.  I just have to
let the program finish.  This can be quite annoying if I was running
something like find /.  The general fix seems to be to unload cygwin1.dll by
exiting all bash sessions, which is obviously less than optimal.

3) The following two commands cause bash to hang for several seconds before
executing properly.  I believe that bash is, for some reason, going out to
the LAN before figuring out what to do.  Could it be related to bug #1?
   cd /
   cd relativepath/subdir
Other symptoms:  after experiencing this bug, an immediate retry of these
two commands will usually work speedily (which is why I believe that it is
related to something cached on the network), but waiting a little longer
causes a replay of the original several-second hang.

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
      ...

5) vim 5.3 is badly broken using TERM=linux.  After starting it, if I hit
backspace once or twice quickly, it hangs in an infinite loop.  Sending it a
signal from another shell prompt causes it to report:
   Vim: Caught deadly signal TERM
   Vim: Finished.
after which the shell is hosed (because vim didn't reset it when it exited).
Trying TERM=ansi works ok except that the function keys aren't defined.
TERM=xterm works for function keys 5-8, but not 1-4.  I eventually made my
own terminal definition based on xterm which properly defines function keys
1-4, too.  Could it be that I'm the only one using vim which has this
problem (I didn't see it in the archives)?

6) I can't get less to take into account that wrapped lines take up multiple
screen lines.  This has the annoying side effect of scrolling the top few
lines off the screen.  The only workaround I've found is to use fold -w79 |
less.

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.

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
gets totally lost and requires that GCC_EXEC_PREFIX be defined.  It would be
nice for gcc to try a few other likely places before giving up.  For
example, gcc might try ../lib/gcc-lib relative to the directory where gcc is
found.  Also, I couldn't find any documentation about what value to use for
GCC_EXEC_PREFIX.  It's not obvious that it should be set to cpp's parent's
parent's directory.

9) bash's internal "set" command doesn't appear to be interruptable with
cntl-c.  

10) zip (built according to the directions at ftp.franken.de) fails when
redirecting output to a UNC path, e.g. 
   zip -r - . >//h/mystuff.zip
reporting:
   zip error: Internal logic error (incorrect compressed size)

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 think that silently ignoring such
errors when called with the -p option is a more proper behavior, because
there doesn't seem to be a good reason to squawk when the file has been
successfully copied and it's only the file ownership which can't be set
correctly.

12) Under cygwin 19, "ls -lF /" didn't need to hit my floppy drive, even
though a: was mounted as /a.  But under cygwin 20 it does, forcing me to use
something less intuitive than /a (so that whenever I don't have to wait
while the floppy disk grinds whenever I get a listing of /).

Output of cygcheck -s -r -v:

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Mon Jun 21 18:05:14 1999

WinNT Ver 4.0 build 1381 Service Pack 4

Path:	/jrw/jrw/mdst/sh
	/jrw/binu
	/opt/cygwin/local/bin
	/opt/cygwin/bin
	/opt/cygwin/bin
	/jrw/binw
	/winnt/system32
	/winnt
	.

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

CYGWIN = `  notitle tty nostrip_title binmode glob'
GCC_EXEC_PREFIX = `/opt/cygwin/lib/gcc-lib/'
HOME = `/jrw'
MAKE_MODE = `UNIX'
PWD = `/jrw/jrw/mdst/mab'

...<snip>...
CDPATH = `.:..:/jrw'
COLUMNS = `80'
LINES = `67'
...<snip>...

HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `C:'
  unix = `/c'
  fbinary = 0x00000001
  fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
  (default) = `A:'
  unix = `/a/a'
  fbinary = 0x00000001
  fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
  (default) = `D:'
  unix = `/'
  fbinary = 0x00000001
  fsilent = 0x00000001
HKEY_CURRENT_USER\Software\FTP Explorer\Profiles\cygnus
  (default) = `sourceware.cygnus.com'
  Login = `anonymous'
  InitialPath = `/pub/cygwin'
  AnonLogin = 0x00000001
  CacheData = 0x00000000
  Description = `'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
...<snip>...
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
  (default) = `d:\opt\cygwin\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnu
s Cygwin B20
  (default) = `C:\WINNT\IsUninst.exe -fd:\opt\cygwin\cygwin-b20\Uninst.isu'
  DisplayName = `Cygwin B20'

a:\ fd  FAT        1Mb  39% CP    UN           
c:\ hd  FAT     2044Mb  29% CP    UN           
d:\ hd  NTFS    4104Mb  26% CP CS UN PA FC     
e:\ cd           N/A    N/A                    
f:\ net NWFS     900Mb  39% CP                 SYS
...<snip>...

D:    /        native  text=binary
A:    /a/a     native  text=binary
C:    /c       native  text=binary

Found: D:\opt\cygwin\bin\bash.exe
Found: D:\opt\cygwin\bin\cat.exe
Not Found: cpp (good!)
Found: D:\opt\cygwin\bin\find.exe
Found: D:\opt\cygwin\bin\gcc.exe
Found: D:\opt\cygwin\bin\gdb.exe
Found: D:\opt\cygwin\bin\ld.exe
Found: D:\opt\cygwin\bin\ls.exe
Found: D:\opt\cygwin\bin\make.exe
Found: D:\opt\cygwin\bin\sh.exe

  371k 1998/12/01 D:\opt\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=1998/12/1 3:25
    5k 1998/12/01 D:\opt\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 1998/12/01 D:\opt\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
  600k 1998/12/01 D:\opt\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=1998/12/1 3:28
  446k 1998/12/04 D:\opt\cygwin\bin\cygwin1-old.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=1998/12/3 23:39
  451k 1999/06/15 D:\opt\cygwin\bin\cygwin1-recommended.dll - os=4.0 img=1.0
sys=4.0
                  "cygwin1.dll" v0.0 ts=1999/1/16 0:09
  451k 1999/01/16 D:\opt\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=1999/1/16 0:09

Anyway, even with these problems, cygwin is a life-saver for someone having
to work in a windows environment.  It's amazing that it's so usable!  Thanks
guys!

John Wiersba (john.wiersba@medstat.com)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com