Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
From: "Roger Vaughn" <rvaughn AT seaconinc DOT com>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: RE: Cygwin 1.0 "issues"
Date: Tue, 26 Oct 1999 20:54:35 -0400
Message-ID: <NDBBKDNNBCDFDHCBEPNGOENLCAAA.rvaughn@seaconinc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <19991026161931.A1857@cygnus.com>

Chris,

Thanks for the response!  Now let's see what I can do with this.....

> -----Original Message-----
> From: cygwin-owner AT sourceware DOT cygnus DOT com
> [mailto:cygwin-owner AT sourceware DOT cygnus DOT com]On Behalf Of Chris Faylor
>
>
> On Tue, Oct 26, 1999 at 03:48:49PM -0400, Roger Vaughn wrote:
> >Try this exercise out to see just how broken this handling is.
> Start any of
> >the Cygwin shells.  cd to /usr.  Now cd to c:/windows (a path B20.1
> >understands...).  What do you get?  The path "/usr/c:\windows".
> A horribly
> >invalid path!
>
> Hmm.  When i try this and type pwd the path is "/cygdrive/c/windows".
> Are you sure that you're running the bash that came with the CD?

Interesting.  I use tcsh rather than bash, so this might be the source of my
problem - bugs in the (Cygwin-supplied) tcsh port.  I already noticed
problems in the command-line editing, so this wouldn't be a surprise.

Ok, I tried this again.  Turns out that both bash and tcsh handle this
correctly under the covers (makes sense - cygwin1.dll is the real customer.)
Tcsh concatenates both paths in its prompt, however, as I mentioned earlier.
That's good at least - it's just a presentation bug and not a show stopper.

> You may have been bitten by a bug tha I mentioned earlier.  Take a look
> at your mount table and see if you have two root entries.  If you do,

I'm very sure this isn't it - I have been playing with the mounts quite a
bit.

> Regardless, if this is not working this way for you, it's a bug, not an
> insidious plan on our part to eradicate Windows style paths.

Refreshing to know, even if it is a laudable goal.  :-)

> Well, the intent of the CD was to provide a UNIX environment.  All of the
> advertising states "UNIX on Windows".  I don't think that it is surprising
> that you get a UNIX environment when you install Cygwin.

A fair statement.  I tend to think of Cygwin as "UNIX utilities on Windows",
rather than a whole environment.  That's the way I have integrated the
toolset into older projects, anyway.    I would still like Cygwin to at
least be able to use Windows-style paths when fed them - regardless of how
they are kept internally.  This doesn't currently seem to be the case, but
perhaps I should check again.

> If you would like to provide more details than "everything goes screwy!"
> then perhaps we can work on solving whatever problems you're seeing.
>...
> I don't exactly see how changing the path handling code from using //c
> to /cygdrive/c will causes problems.  Maybe you'll enlighten us with
> more details and then I'll understand.

This was a mystery to me as well.  Just setting up the mount structure
shouldn't cause anything to fail - the paths should still pick the right
binaries....  And unfortunately, I can't (right now) tell you exactly what
happened, 'cause I promptly forgot the exact behavior after seeing it.

I'll try to replicate this, but here's my setup.  I have Cygwin installed in
the default C:\Cygwin.  From years of digging up various utils, I already
have a somewhat UNIX-like structure on my disk - C: contains a /bin, /tmp,
/usr, etc.  Where I ran into the "screwy" was somehow related to either Amol
Deshpande's (sp?) native tcsh port, or the sh.exe copied from Cygwin, both
of which I have in c:/bin.  My path contains c:/bin.  When I attempt to
mount c:\ as /c and try to use Cygwin's tcsh, the Cygwin utils start to
misbehave in unpredictable ways.  (Wish I could describe, sorry.)  I'm
*guessing* this is some bizarre conflict between my c:\bin, Cygwin's
emulated /bin, and my c:/bin path mapping.  When I umount /c - and change
nothing else - the Cygwin set behaves perfectly.

I found most of these difficulties while building GCC 2.95 and XEmacs
21.1.7.  Here's a big path conflict I found while doing this - "configure",
of course, runs "sh", which it picked up from Cygwin.  So it generates a
Makefile with Cygwin-style paths.  Then I attempt the build in the
non-Cygwin tcsh.  (Not consciously, but because this environment - except
the Cygwin update - is one I have successfully used for years.)  Which works
for the most part but fails because tcsh can't deal with the Cygwin paths at
some point late in the build.  Fortunately I was able to use the Cygwin tcsh
to complete the build.  But I can't imagine that this will turn to be an
infrequent conflict.

Other than that I have a hell of a time with my XEmacs and tmp paths.
Because of the internal code and the external utils Emacs uses, sometimes it
needs Cygwin paths, sometimes Windows paths.  I have noticed this
specifically in the XEmacs package-handling extensions - XEmacs will run ftp
to download a package, but then can't find where it ended up, presumably
because a Cygwin util wrote a path spec which a later Windows util couldn't
understand.  As yet I have found no way around this except to either use the
Cygwin XEmacs with only Cygwin utils, or use the native XEmacs with only
native utils.  And I'm not thrilled about either solution.....

I suppose the point I am trying to make out of all of this is that I didn't
have this sort of path incompatibility trouble with b20.1 and earlier.
Perhaps this is just because of the increased scope of the 1.0 release.

Thanks,

rog


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com