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

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Jerome Guitton
> Envoyé : lundi 10 décembre 2012 19:22
> À : gdb-patches@sourceware.org
> Objet : Re: [RFA/mingw32] environment variables are case-insensitive on
> win32
> 
> Corinna Vinschen (vinschen@redhat.com):
> 
> > Only the Win32 function GetEnviromentVariable searches the environment
> > case-insensitive, and SetEnviromentVariable overwrites the first
> > occurence of a variable after a case-insensitive search.  These
> > functions are also used by CMD.EXE, so that it's case-insensitive as
> > well.
> >
> > But that doesn't affect the ability to handle case-sensitive
environments
> > in applications NOT using GetEnviromentVariable/SetEnviromentVariable.
> >
> > If you give an environment to the CreateProcess function it will go
> > unchanged to the inferior process.  Fetching the complete environment
> > with GetEnvironmentStrings in the inferior will show the full,
> > unchanged, environment, with as much variables only differing by case as
> > you like.
> 
> Thank you very much for this clarification Corinna!
> 
> At this point I feel that the most sensible thing to do for mingw32 is
> to have case-insensitive env vars, even though on certain
> circonstances case-sensitivity would work. I have one other good
> reason to think that: the path command does not work today in mingw32
> when running the debugger from CMD.EXE. That is caused by the fact the
> corresponding environment variable has a different casing than PATH:
> it's 'Path' (at least on my machine). So a case-sensitive lookup
> fails, a new variable 'PATH' is created in the environment vector, and
> the inferior ends up with a truncated environment.

That is strange because when I start a mingw32 compiled GDB executable
from a console 
"show env" command does indeed display
Path variable,
but nonetheless GDB is perfectly able to use Path variable...

(gdb) show env
ALLUSERSPROFILE=C:\ProgramData
<<<<Lines removed
OS=Windows_NT
Path=C:\Program Files (x86)\MiKTeX 2.9\miktex\bin;C:\Program Files
(x86)\Windows
 Resource Kits\Tools\;C:\Program Files\Common Files\Microsoft Shared\Windows
Liv
e;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System3
2\Wi
ndowsPowerShell\v1.0\;C:\Program Files\Dell\DW WLAN Card;c:\Program
Files\WIDCOM
M\Bluetooth Software\;c:\Program Files\WIDCOMM\Bluetooth
Software\syswow64;C:\Pr
ogram Files (x86)\NTRU Cryptosystems\NTRU TCG Software Stack\bin\;C:\Program
Fil
es\NTRU Cryptosystems\NTRU TCG Software Stack\bin\;C:\Program Files\Wave
Systems
 Corp\Gemalto\Access Client\v5\;C:\Program Files (x86)\Common Files\Roxio
Shared
\DLLShared\;C:\Program Files (x86)\Common Files\Roxio
Shared\10.0\DLLShared\;E:\
pas\svnbin;C:\Program Files\Intel\DMIX;C:\Program Files (x86)\MySQL\MySQL
Server
 5.5\bin;e:\pas\fpc-2.6.0\bin\i386-Win32;C:\Program
Files\SlikSvn\bin;C:\Program
 Files (x86)\Dr. Memory\bin;C:\Program Files (x86)\PuTTY;C:\Program Files
(x86)\
OpenVPN\bin;C:\Program Files
(x86)\OVPSim\Imperas\bin\Windows32;C:\OVPSim\Impera
s\bin\Windows32
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
<<<<Lines removed
COLUMNS=80
(gdb) file drmemory.exe
Load new symbol table from "C:\Program Files (x86)\Dr.
Memory\bin\drmemory.exe"?
 (y or n) y
Reading symbols from C:\Program Files (x86)\Dr.
Memory\bin\drmemory.exe...(no de
bugging symbols found)...done.

I don't know why this doesn't work for you.

Pierre