From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6604 invoked by alias); 26 Jul 2012 18:42:19 -0000 Received: (qmail 6514 invoked by uid 22791); 26 Jul 2012 18:42:18 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_CG X-Spam-Check-By: sourceware.org Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jul 2012 18:41:52 +0000 Received: by yenq11 with SMTP id q11so2373764yen.2 for ; Thu, 26 Jul 2012 11:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr22540453paw.63.1343328110999; Thu, 26 Jul 2012 11:41:50 -0700 (PDT) Reply-To: sebastian@smashd.net Received: by 10.68.23.9 with HTTP; Thu, 26 Jul 2012 11:41:50 -0700 (PDT) In-Reply-To: <20120725225407.GA17313@ednor.casa.cgf.cx> References: <20120725225407.GA17313@ednor.casa.cgf.cx> Date: Thu, 26 Jul 2012 18:42:00 -0000 Message-ID: Subject: Re: environment variables & mks toolkit - patch opportunity? From: "M. Sebastian Comella" To: cygwin@cygwin.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-07/txt/msg00593.txt.bz2 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 >>2002-vintage thread: >> >>http://www.cygwin.com/ml/cygwin/2002-07/msg00734.html >> >>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. > > cgf > 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 in parens): SHELL (C:/PROGRA~1/MKSTOO~1/mksnt/sh.exe) TERM (dumb) TERMCAP (C:\PROGRA~1\MKSTOO~1\etc\termcap) TERMINFO (C:\PROGRA~1\MKSTOO~1\usr\lib\terminfo) 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? Thanks, Sebastian. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple