Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Reply-To: <rvaughn AT swprocurement DOT com>
From: "Roger Vaughn" <rvaughn AT swprocurement DOT com>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: Cygwin 1.0 "issues"
Date: Tue, 26 Oct 1999 15:48:49 -0400
Message-ID: <NDBBKDNNBCDFDHCBEPNGCENFCAAA.rvaughn@swprocurement.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal

I just got the Cygwin 1.0 CD, and an issue has come up that bugs me quite a
bit.

It's about the new drive-mapping scheme built into Cygwin.  Older versions
of Cygwin understood native Windows-paths (with maybe minor tweaking).  This
no longer seems to be the case, and Cygwin seems intent on translating to
its internal scheme - either /cygdrive/x/path or the just plain unix-like
/path.

This seems like a huge step backwards to me - this has severely decreased
the interoperability between Cygwin utils and native Windows tools.  (I use
native builds of Emacs, tcsh, and others - and see no reason to have to
recompile all of these.)  Cygwin tools will no longer understand the native
paths, and the native tools cannot understand Cygwin paths.

I can make the mental translations, sure - but I find myself forgetting
which utility comes from where (i.e. which path it needs), which is
frustrating to me - and I can't even begin to imagine what kind of
frustration this will cause users whom I have to roll some of this stuff out
to.

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!

Mounting my C:\ as /c isn't an option, because as I stated above, my *other*
tools then cannot understand /c/path.

This caused me many, many headaches this past weekend with builds of gnu
tools, and with my emacs setups.

I would like to have all of my tools working together - not create a new
insular unix-like environment that just happens to run inside Windows.
Otherwise I might as well just boot up my Linux environment...

Is there any way to make Cygwin behave like older version did?  What does
the community think about this issue?


A related question is the "more similar to Unix directory structure".  Why
don't we stop puttering around and just go all the way with this?  For one,
the "almost, but not quite" structure makes it difficult to update Cygwin
components - like gcc.  This actually didn't used to be much of a problem
for me, since I replicated the Unix directories on my own.  But now -
especially with the new pathing scheme above, this has become much more
difficult.  (In fact, mounting my C:\ drive, which has a Unix-mimic
structure on it, as /c in Cygwin causes some sort of conflict with Cygwin
itself and everything goes screwy!)


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