Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: Earnie Boyd cc: "Parker, Ron" , "'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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Mar 2000, Earnie Boyd wrote: > --- Mo DeJong 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.