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

[Brian Dessent <brian at dessent dot net>]

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

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.

(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.)

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.

Brian