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]

Re: Environment passing bug?

On Feb 21 14:19, Charles Wilson wrote:
> $ ./envprint.exe  | grep -i temp
> 'TEMP=C:\cygwin\tmp'
> 'temp=C:\Temp'
> 'tmp=C:\Temp'
> ====== xp-64 ========
> ...and the only mystery now is how my $ATWORK stuff should deal with the
> fact that there are TWO different copies of the "same" variable in the
> environment, if the $TESTAPP is started from cygwin rather than plan old
> dosbox.
> ...or, is it possible that cygwin should not export both copies of
> TEMP/temp, TMP/tmp when spawning a native process?

I wouldn't want that.  Even if the Win32 functions GetEnvironmentVariable
and SetEnvironmentVaribale handle variable names case insensitive, the
GetEnvironmentStrings function returns the environment block verbatim.
So it's kind of your application's own problem if you don't handle that

Also, in cases like this:

  bash$ export FOO=FOO
  bash$ export foo=foo
  bash $ cmd
  C:\> bash
  echo $FOO $foo

I would like to see the output

  FOO foo

and not just "FOO" or "foo", depending on which came first.

Also, if you merge them, how do you know which one is the one you need
for your Win32 application?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

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