This is the mail archive of the
mailing list for the Cygwin project.
Re: environment variables & mks toolkit - patch opportunity?
On Wed, Jul 25, 2012 at 5:54 PM, Christopher Faylor wrote:
> On Wed, Jul 25, 2012 at 05:43:52PM -0500, M. Sebastian Comella wrote:
>>Hi all -
>>I recently lost a good chunk of my day tracking down a Cygwin issue
>>ultimately caused by an installation of IBM InfoSphere. The InfoSphere
>>installer surreptitiously installed MKS Toolkit, which in turn set a
>>bunch of environment variables that left Cygwin in a very unhelpful
>>state: attempting to start Cygwin via its usual mintty shortcut would
>>appear to hang, with mintty showing "sh.exe" in its title bar and
>>little else. The cause of the issue is unfortunately not very obvious
>>since there is no error message or other form of reporting. If I had
>>realized that MKS Toolkit was being installed I might have had a
>>fighting chance, but without that info I was in the dark.
>>Fortunately, fixing the issue is pretty easy and is a matter of
>>removing some Windows environment variables, as noted in this
>>My question is this: is there an opportunity to patch something in
>>Cygwin's startup "chain" to detect unsavory environment variables and
>>warn users in some fashion? I'm not sure what package (or core
>>process) could detect the situation and still get a warning off to the
>>user before everything goes fubar. Putting a check into the installer
>>may also be a viable solution, considering that the first thing I did
>>was run the Cygwin installer again to see if it could "repair" things.
>>I think I can take care of writing the patch, but I'd like some input
>>on where it even belongs before I give it a shot.
> If you can provide an exact environment variable which caused a problem
> we can look into whether this is actually a problem in Cygwin, although
> it seems unlikely that it is. Cygwin is meant to read environment
> variables from... its environment. If you set them incorrectly bad
> things can happen. Cygwin is no different than UNIX in that regard.
> We're can't add special case handling for a bunch of random environment
> variables because someone reported that they think they might have
> caused a problem. We need more details than that.
The variables (as defined on my system) definitely caused a problem
when attempting to start a Cygwin terminal. While they were present,
attempting to open a Cygwin terminal via the usual mintty shortcut
left me at an empty console screen with "- sh.exe" in the title bar,
and no CPU or process activity to speak of. Removing them let the
shell start normally again. No other changes on my part were
necessary. Of the variables mentioned at the link, these variables
seemed to be the most troublesome (MKS Toolkit values from my system
MKS Toolkit set these variables when it was installed. It also
prepended PATH with its own bin directories, so "which sh" would
resolve to MKS's copy. Removing these variables and cleaning up the
PATH took care of the core issue, but I decided to remove all of the
entries referenced at the link to ensure I wouldn't run into other
issues down the line.
My concern is that I did not set these variables, an installer (that
installed MKS Toolkit) did. Therefore I had no idea that new
environment variables were introduced and causing issues, because
there was no warning or output from Cygwin to even hint at the cause.
I was chasing down everything in the BLODA, rebasing DLLs, etc, before
I had the thought that the "sh.exe" in the terminal title might not be
Cygwin's sh.exe. That's how I found the MKS install directory and
ultimately that link about MKS-related issues.
I'm not blaming cygwin or calling it a bug in cygwin, I'm suggesting
that we add an environment "sanity check" somewhere to warn users if
it looks like they've set some things that could cause trouble. It
could even be so specific as to check for MKS Toolkit values. Or
barring that, maybe it's as simple as adding an entry in the BLODA?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple