X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_KL,TW_NV,TW_VB
X-Spam-Check-By:	sourceware.org
Message-ID:	<4F42D201.4000901@cwilson.fastmail.fm>
Date:	Mon, 20 Feb 2012 18:06:41 -0500
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows NT 5.2; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Environment passing bug?
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

--------------020803050204050502060000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I've observed different behavior with cygwin-1.7.0 on 64bit XP, and
32bit XP (I'll check Vista-32 and W7-64 later tonight).  Using the
following attached win32 program:

$ i686-pc-mingw32-gcc -o envprint envprint.c

====== xp-64 ========
$ uname -a
CYGWIN_NT-5.2-WOW64 abcdefgh 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin

$ ./envprint | grep -i temp
'TEMP=C:\cygwin\tmp'
====== xp-64 ========



====== xp-32 ========
$ uname -a
CYGWIN_NT-5.1 ijklmnopq 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin

$ ./envprint | grep -i temp
'TEMP=C:\cygwin\tmp'
'temp=C:\TEMP'
'tmp=C:\TEMP'
====== xp-32 ========


This is actually causing an issue $ATWORK on the *32bit* side.  We have
our own getTempDir function -- which has certain behavior related to the
variables TEMP, TMP, and TMPDIR, as well as a fallback behavior when all
three are unset.

Being good little software engineers, we have a testsuite that validates
all this behavior.  One of those tests explicitly unsets TEMP, TMP, and
TMPDIR, and attempts to verify the fallback behavior.  However, in the
32bit case, when the test program is launched from cygwin...our getenv
function ("TEMP") actually finds the "temp" variable, since we only
unset the capitalized ones.  (launching from a regular dos box doesn't
have this problem, as there is only the one TEMP variable -- but I
*like* using a cygwin shell!)

Now, we could easily unset both forms TEMP and temp
(+TMP,tmp,TMPDIR,tmpdir...and TmPDiR, etc? or explicitly loop thru the
envblock and do a case-insensitive compare, etc etc). Or we could just
say "don't use a cygwin shell to run these tests".  So we have a
workaround, but the observed behavior does seem odd.


Why does cygwin itself behave differently with respect to the envblock
that it passes to native exes that it launches, when running (under
32bit WOW64) on a 64bit machine, and on a 32bit machine. Surely /THAT/
at least is unexpected?

Is this a bug that should be fixed, or what?

--
Chuck

--------------020803050204050502060000
Content-Type: text/plain;
 name="envprint.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="envprint.c"

#include <stdlib.h>
#include <stdio.h>
#include <windows.h>

int main(int argc, char* argv[])
{
  LPTCH envblock;
  LPTCH p;

  envblock = GetEnvironmentStrings();
  p = envblock;
  while (strlen(p) > 0 )
  {
	 fprintf(stdout, "'%s'\n", p);
     p += strlen(p) + 1;
  }
  FreeEnvironmentStrings(envblock);
  return 0;
}



--------------020803050204050502060000
Content-Type: text/plain; charset=us-ascii

--
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
--------------020803050204050502060000--

- Raw text -