This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [HEADSUP] Let's start a Cygwin 1.7 release area


On Apr  4 09:52, Brian Dessent wrote:
> Igor Peshansky wrote:
> 
> > On Windows it can't.  To be able to run the application, the Windows
> > loader needs to be able to access all of the dependent DLLs (unless they
> > are dlopen'ed).  So, if some DLLs are not in the PATH, bash wouldn't run
> > far enough to execute /etc/profile.
> 
> I have to say I don't understand this desire to decouple /bin and
> /usr/bin at all.  Having them as two distinct directories means:
> 
> - setting PATH is more complicated and error prone
> - PATH is now longer and every exec() has to search a new directory
> - packaging requires more decisions and opportunity for error
> - scripts that were lazy and used one or the other without thinking need
> updating
> 
> It seems to me that the reasoning for doing this is:
> 
> - it makes fstab cleaner not to have to redefine these two identity
> mounts, since it requires duplicating the Win32 location of the Cygwin
> root
> - it makes things more like linux

- Directory search is getting slower the more entries you have.
  By keeping the base tools and the DLLs in one dir, and the not-so-base
  tools in the other dir, you have a chance of getting a quicker directory
  search.

> For the first point, we can easily solve that just by inventing some
> syntax that allows to define a new mount relative to an existing mount,
> e.g. by specifing a posix path instead of a win32 path for the first
> argument, so:
> 
> /bin /usr/bin ntfs binary 0 0
> 
> The rule can be that if the first word starts with a "/" it's a relative
> mount.

I don't think that's really necessary.  It's possible, though you have
to take care that the order in fstab makes sense.

> (Aside: What are we to do about Win32 paths that contain whitespace when
> the format of the file is space separated words?  I fear the code will
> need to accept doublequoted first and second words.)

Same as on Linux.  I've not yet applied the patch but it works already.
The path should always be given with forward slashes, it's nut actually
a must, though.  However, if the path contains spaces these can be
escaped as `\040'.

> For the second point I'd like to posit that the logic for having two bin
> dirs dates back to old unix practices like having /usr on a nfs mount,
> such that /bin was the only available thing at system bootup time.  We
> don't have any of that to worry about really, as nobody does that kind
> of thing (I hope) with Cygwin.  So purposefully bifurcating a bin dir
> into two locations seems like it's just breaking things and creating
> more work all in the name of blind emulation.

I understand the point you're trying to make, but...

I found it always a bit weird *not* to have a separate /usr/bin dir.
One disadvantage we have is that a package which accidentally uses
a leading dot in the path (./usr/bin/foo) getys installed into a *real*
/usr/bin dir by setup.  Personally I find it cleaner to have two dirs.
One thing which bugs me is that installing stuff into external
directories, which is quite normal otherwise (Windows: Every app
has it's own dir under C:/Program\040Files, POSIX: /opt) is avoided
in Cygwin just because people might run into trouble due to a lacking
$PATH.  Do we really need to avoid everything, just because it makes
the average Windows user unhappy?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]