Mail Archives: cygwin/1999/10/26/22:07:19
On Tue, Oct 26, 1999 at 08:54:35PM -0400, Roger Vaughn wrote:
>> 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.
Ok. The tcsh on the CD was pretty much a straight port. We didn't go
out of our way to make it understand MS-DOS paths. It wasn't a goal for
any of the utilties that we ported.
>I'm very sure this isn't it - I have been playing with the mounts quite a
>bit.
>
>>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.
Cygwin *can* use Windows-style paths. Didn't you just admit this?
If you mean that some utilities, like tcsh, can't handle them, then, of
course, you're right. There's not much we can do about that. We
certainly don't have the staff to start a crusade of modifying every
application to understand the c:\ path specifications. In fact, one of
the early goals of cygwin was to create a layer which avoids this to
make porting the GNU tools easier.
>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.
My layout is pretty similar to this and I'm not having problems.
If you have two different cygwin DLLs on your system, though, you're
asking for trouble.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -