RE: [RFA/mingw32] environment variables are case-insensitive on win32

Pierre Muller
2012-12-11T15:23:39Z

> > However, when a Cygwin process gets started by a *non*-Cygwin process,
> > this internal mechanism can't work, and the POSIX environment is created
> > from the Windows environment. Up until 2008, all environment variables
> > in the Windows env were converted to uppercase when creating the POSIX
> > env. In 2008 we changed that mechanism to uppercase only a certain set
> > of env vars, and that's done up to today for compatibility reasons. The
> > list of still uppercased vars is this:
> >
> > ALLUSERSPROFILE
> > COMMONPROGRAMFILES
> > COMPUTERNAME
> > COMSPEC
> > HOME
> > HOMEDRIVE
> > HOMEPATH
> > NUMBER_OF_PROCESSORS
> > OS
> > PATH
This explains why Cygwin doesn't show the same problem
as mingw does.
You never end up have Path variable...

> > PATHEXT
> > PROCESSOR_ARCHITECTURE
> > PROCESSOR_IDENTIFIER
> > PROCESSOR_LEVEL
> > PROCESSOR_REVISION
> > PROGRAMFILES
> > SYSTEMDRIVE
> > SYSTEMROOT
> > TEMP
> > TERM
> > TMP
> > TMPDIR
> > WINDIR
>
> Then, the situation of GDB (a Cygwin process) starting the inferior with
> CreateProcess ends up being the same as if GDB was not a Cygwin process, and
> that set of vars always ends up uppercased in the inferior, right? Or does
> Cygwin have some magic that detects the case, and avoids the uppercasing in
> this case?

Coming back to the mingw32 case,
currently you can perfectly pass both Path and PATH environment variables to debuggee.
If this debuggee is cmd.exe, the funny thing is that it will use
the value of Path rather than that of PATH ....
Let me show to you:
(gdb) file cmd.exe (output suppressed)
(gdb) set env PATH=e:\pas\svnbin
(gdb) set env Path=c:\windows\system32
(gdb) run
e:\
set
lists both Path and PATH
...lines suppressed
OS=Windows_NT
Path=c:\windows\system32
PATH=e:\pas\svnbin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
...lines suppressed
but
svn.exe (present in e:\pas\svnbin)
is not found...
%PATH%\svn.exe
also doesn't work, because cmd.exe
expands %PATH% to the value of Path variable...

Isn't this all strange...

Pierre