Delivered-To: listarch-cygwin AT sourceware DOT cygnus DOT com Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Mon, 15 Feb 1999 14:39:45 -0500 From: Steve Coleman Subject: Re: New "feature" introduced with winsup automount? Sender: slc AT aplgate DOT jhuapl DOT edu To: cygwin AT sourceware DOT cygnus DOT com Message-id: <36C87801.C994E4DF@jhuapl.edu> Organization: Johns Hopkins Applied Physics Laboratory MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4m) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <36C4B42F DOT 17E6ED6 AT jhuapl DOT edu> <19990213163118 DOT A590 AT cygnus DOT com> Christopher Faylor wrote: > I'm not sure why you are installing pthread.dll. This has nothing > to do with cygwin. I stand corrected. I guess I just _assumed_ (and we both know what that means) that the pthread support would utilize the work from the sourceware pthreads-win32 project at Cygnus. After all most Unix environments have to include a separate library to get pthread support (i.e. -lpthread). > You deleted a registry entry??? Do you really think that is the > proscribed way of doing things? No, in fact I know that this is not the correct way to handle it. I was just trying to find out 'how it works' on my own without having to study all the latest source code changes (its all new to me). Often in the Windows environment the behavior of things like this can be tailored through the registry, I was just trying to see what it did. Sometimes when you live on the bleeding edge without documentation you have to take a little risk. :-> As a designer/developer of a large scale high-performance distributed processing system, cross platform portability is a big issue for me. In that respect I am _very_ impressed with the work that Cygnus has done so far. I guess I just get a little antsy when I see behavior which I don't see in any of my many Unix environments. My first goal is to understand why, my second is to learn how to deal with it. I can certainly appreciate having an alternate way of mapping the drives into directories as I can see this being very useful in the Windows environment. It's just that when I cd to a directory and 'pwd.exe', $cwd, nor '$PWD' agree with where I think I am, I can't help but wondering what scripts might break. For instance, what if a script were used to move a series of directory structures by the following command: "tar - $PWD/$1 | rsh $host tar xvf -" where the destination path "$host:/cygdrive///$1" does not exist but "$host://$1" did, and it was mounted from a different drive or even on a Unix system? Yes I agree, this one is an easy fix, but it is also completely preventable. If the default behavior was to map $PWD ($cwd, $HOME, etc.) to / rather than the /cygdrive/x/ syntax, then we would not have to rewrite any scripts. The alternate syntax would of course be available for accessing things outside of the normal directory tree. Q:Might this mapping also affect automated remote distribution programs like rsync and ftp as well? > >a2dslc:/c/Gnu/home/coleman:% ls -al //D/ > >ls: //D/: No such file or directory > > Ah. Well, this probably explains things. You're not using the latest > snapshot. You're apparently using a snapshot from a week or so ago. Behind? Probably, it took me about a week (part time) to build the whole tree. There were a lot of header files (or links to them) that did not seem to make it into the i686-pc-cygwin32 directory tree structure. I had to keep restarting the build after each minor correction. Now that I've done it once I'll try to keep it up to date. ;-) Please keep up the good work! Thanks. -- Steve Coleman http://www.jhuapl.edu/ <<--------->> Johns Hopkins Applied Physics Laboratory <<---------->> Balt:443-778-6330 Fax:443-778-5597 Wash:240-228-6330 Fax:240-228-5597