On Apr 3 11:16, Igor Peshansky wrote: > On Thu, 3 Apr 2008, Corinna Vinschen wrote: > > [snip] > > > >>> Get own path ==> C:\\cygwin\\bin\\cygwin1.dll > > > >>> Where's fstab? ==> C:\\cygwin\\etc\\fstab > > > >> > > > >> So, it implicitly computes where / is? > > > > > > > >No, it doesn't. It just snips away the last two path components and > > > >tacks the etc/fstab string on. Plus the .$SID to get the user mounts. > > > > > > > >After the mount points have been read, root can potentially be > > > >somewhere else entirely. > > So would it make sense to put the root mount info in the same directory as > cygwin1.dll? I know it doesn't belong in /bin, but playing with relative > paths is even more error-prone.
I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. > > [snip] > > > For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <> > > > /usr/lib. The rationale for keeping those linked no longer applies in > > > the modern setup.exe world. > > > > Full ACK! However, this needs a bit of careful revisiting of some of > > the packages. For instance, assuming the Cygwin DLL will go to /bin, > > cygrunsrv should also reside in /bin when we do this, not in /usr/bin, > > obviously. > > Umm, i don't see how that follows. cygrunsrv can easily reside in > /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked > from the shell, and (b) when cygrunsrv installs the services, it adds /bin > to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. > > Right now I must admit that I prectically don't care if my packages > > install the binaries in /bin or /usr/bin. > > /bin should contain programs that should work even if the PATH and mounts > are screwed up. So, "kill", "shutdown", etc. And cygrunsrv. > > However, that's not really necessary anymore with /etc/fstab. > > So I agree, we can simply get rid of fstab.$SID. > > Yes, that reasoning is mostly correct. However, some packages (like > Cygwin/X) apparently assume a single-user installation, and create > sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat