This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Environment passing bug?

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
====== 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
====== 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?


Attachment: envprint.c
Description: Text document

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]