Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
X-Authentication-Warning: abomination.cygnus.com: mdejong owned process doing -bs
Date: Thu, 30 Mar 2000 14:26:53 -0800 (PST)
From: Mo DeJong <mdejong AT cygnus DOT com>
To: Earnie Boyd <earnie_boyd AT yahoo DOT com>
cc: "Parker, Ron" <rdparker AT butlermfg DOT com>,
        "'cygwin-developers AT sourceware DOT cygnus DOT com'" <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: RE: Mo Dejong's install problems
In-Reply-To: <20000330151528.18901.qmail@web125.yahoomail.com>
Message-ID: <Pine.LNX.4.10.10003301405220.11324-100000@abomination.cygnus.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 30 Mar 2000, Earnie Boyd wrote:

> --- Mo DeJong <mdejong AT cygnus DOT com> wrote:
> -8<-
> > Well, I found that C:/Cygwin/.bashrc was working for me, but this

Yes, I installed into C:/Cygwin so it would be mounted as root.
If I understand the just of what you are saying, setting global
env vars in /.bashrc is a bad idea because it will not always
get sourced.

So the obvious question is, where is the "right" place to set env vars
like PATH. Is it /etc/profile? I do not think a .bat file that invokes
bash is the right place to do that. For one thing, it only works with
bash. There is also the fact that it does not work on Win95 or Win98.

> Based on this I can make an assumption that you have C:/Cygwin mounted as the
> root /, correct?  I can also make the assumption that you don't have the HOME
> environment variable set, correct?  If HOME isn't set then bash assumes / to be
> HOME.  Also, BASH is the only package using .bashrc and then only if it is not
> doing the "login" process; which for Cygwin is the usual case.  BASH will use
> the /etc/profile and/or others which I forget exactly OTTOMH when bash thinks
> the login process is happening and will not execute the .bashrc file.  The
> bash.info file suggests that the /etc/profile file sources the ~/.bashrc file.
> 
> > was only by trial and error (I need to apply for a patent on that).
> > Could someone who knows more about cygwin internals comment on why
> > cygwin can not use something like a .bashrc file for global settings
> > instead of a .bat file? 

So are there any reasons that cygwin should not
"emulate the UNIX startup processes"?

> I can't say that I know anything about the "cygwin internals"; but, I'm
> intuitive and a forward thinker so I can answer your question.  Setting global
> variables in the .bat file is the Windows way of doing it.  If you want to set
> globals for a particular process that other processes don't need then the .bat
> file is the place to do that.  Sure, cygwin could use /etc/profile or something
> else that emulates the UNIX startup processes except for the CYGWIN variable
> itself.
> 
> > Is there some reason the PATH would need to
> > be set while still in windows? 

The exact same thing would happen if you just ran one of these shells
from a dos shell without first calling cygwin.bat. Shell in cygwin
really need to work "stand alone", they should not depend on a .bat
file.

> No, I set PATH in the .bashrc file.  However, if I do `sh -c 'foo'' from the
> dos command window then .bashrc isn't read (because sh isn't bash) and the PATH
> doesn't get set properly.  I haven't looked at ash code/documentation to know
> what files it uses to set the environment.
> 
> >Does cygwin fail to correctly
> > "export" the PATH env var or something?
> > 
> 
> Absolutely not.
> 
> > These may sound like stupid questions, but I think this is in fact
> > the most important issue cygwin will face in the next release.
> 
> I don't.  The most important issue in the next release will be the pathing
> changes, the switch to i686-pc-cygwin, and the linker resolution of _ctype_.
> 
> > Previous version of cygwin were just too hard to install. Users
> > need to be able to click a button and have the basics work
> > "out of the box".
> > 

I have heard this argument before. Once a person learns how something
works, they will just assume that other people should be able to figure
it out too. It is nice that you were able to install lots of earlier
versions of cygwin, but there are lots of other people who gave up
on cygwin because it did not work "out of the box" (I am mostly
talking about beta 20 here). Here is how it typically goes.

Engineer> The product works.
Customer> I tried to run it but I could not get it working.
Engineer> You must have done it wrong, go back and try again.
Customer> I just tried it again, I can't figure it out.
Engineer> Well, it works on my box.


> Not at all.  I've installed b18, b19, b20, CD v1.0 and snapshots.  I've never
> had the difficulties that most have; but, as I said earlier I'm an intuitive
> forward thinker.
> 
> > Mo Dejong
> > Red Hat Inc.
> > 

I am not sure what you mean by this. Are you saying that "minor" issues
like "cygwin does not install" and "cygwin does not work" do not belong on
the cygwin developers list?

> BTW, this is off topic for _this_ list; but, because you're an employee of the
> company that owns it I was lenient.
> 
> Regards,


Mo Dejong
Red Hat Inc.