Installation - A Recommended Structure - Comments?

Fred Marshall
Tue Dec 8 11:04:00 GMT 1998

First, let me say that I'm clearly not "in context" with how things work at
the Cygwin "system" level - or how they're supposed to work.  Perhaps
there's value in that.  So, I hope I won't get flamed too badly for making
an observation and a suggestion.  The observation is valid - because it's
what I see.  The suggestion may be terrible!!

There's obviously a lot of good work being done in making the gnu tools
available on WIN32 platforms.  Part of the entire effort is intended to make
solid tools available to a wide audience.  My impression is that only until
a person has slugged through the installation processes at least once or
thrice (then they may have become part of the intelligentsia) all the
information that's being passed around becomes a lot more useful.  I wonder
if the following makes sense to folks:


1)  Cygwin32 is set up and intended to allow porting gnu tools into WIN32
environments.  This appears to make sense for two main types of users:
- UNIX users who find that not using a WIN32 environment is impossible for
various reasons
- WIN32 users who want to make use of the gnu tools but who may not be UNIX
experts at all
and, of course, in addition
- the experts out there at 6 sigma of the population who just want to make
it happen

2) Arguably, the population of WIN32 users who want to make use of the gnu
tools is the largest group of the two main groups and the subset of them who
aren't UNIX experts is a large part of the group.

3) Reliably installing these tools is elusive at best.  It can get to be
really complicated.  Witness the many messages where people are failing to

4) Installation instructions are terse at best and are (randomly?)
distributed over a bunch of readme files, FAQs, etc.  Some of the important
items are labeled or identified in some ways with earlier release numbers -
adding to the confusion.

So, if this is at least somewhere close, might this be a reasonable

5)  Each release (of whatever) should be accompanied by its own installation
instructions and groundrules (disk space is cheap).

6)  Beta testing would urge testing the installation instructions

7)  The instructions would be based on a "standard" configuration - perhaps
a number of them depending on operating system - but preferably one that is
WIN32 OS independent.  What this should be might be a very good topic for

Granted, there are many possible variations - using various gnu and
gnu-related entities that individuals might want to try.  However, reaching
some agreed level of standardization would help reduce the confusion and
focus testing and documentation efforts.

Here's a modest recommendation:

A)  Establish a recommended/standardized WIN32 directory structure that will
work well with the gnu tools.
- Use it.
- Test with it.
- Document it and write instructions around it.  Write for folks who aren't
UNIX experts.  Use WIN32 tools and methods where it makes sense.
(For example, using the NT "Program Files" directory is probably a bad idea
isn't it?  bash or sh commands don't recognize this type of name structure).

B)  Establish methods for setting up WIN32 settings that are important to
the workings of the intended gnu environment.
- Things like what needs to be in the PATH.
- How to get them into the PATH.
Even if there are methods created that will do this automatically, this
information should be available.  For one thing it can be used to check the
results and it can be used to manually set up PATH variables.

Arguments for and against some of this:

Setting directory structures is counter to freedom of expression and
suggests a rigid situation with no flexibility.

Standardizing should not remove flexibility.  However, it should prevent
errors like:  the instructions or some buried code refer to a directory or
path that exists on the author's unique system but don't exist on the

C)  Prerequisite installs are problematic.  If there are prerequisite
installs then there should be some very clear method and map for revealing
this.  Preferably, there would be a roadmap  and instructions for installing
onto a "clean" WIN32 platform.

Pointing to other entities that are higher up (come first) in an
installation hierarchy or sequence can be a major source of confusion and
failure - because they change.  It seems that a well-structured scheme for
doing this would be evident.  It looks like there should be a recommendation
here - but what?  Maybe this is all taken care of by A and B?

In Conclusion:

If your reaction to this is "gee, what's the problem?"  "all of this is
already taken care of!"  RTFM!  Then, I'd suggest that some tiny ingredients
are missing somewhere.  If not missing, then randomly distributed?  Maybe
what we need is a better, more visible, list of recommended reading?

If your reaction to this is "I agree" then responding to this message with
that comment might be useful to see how many such responses ensue.

If your reaction to this is to have better recommendations than those above,
then that's great!  Perhaps at best, this message could be a catalyst.

Most respectfully,


For help on using this list (especially unsubscribing), send a message to
"" with one line of text: "help".

More information about the Cygwin mailing list