Re: PATH vs. Path ([Fwd: Returned mail: see transcript for details]

[Eli Zaretskii]

> Date: Thu, 3 Mar 2005 07:10:54 -0500 (EST)
> From: "Earnie Boyd" <address@hidden>
> Cc: address@hidden
> 
> MSYS and Cygwin as well as the child cmd.exe (at least on NT 5.1) will retain
> 
> export a=A
> export A=a
> 
> in their respective environments.  However cmd.exe, even though both A and
> a are variables, will pick A for either ``echo %a%'' or ``echo %A%'' and
> return the value ``a''.  MSYS and Cygwin have no problem with picking the
> correct variable.  Now in the cmd.exe shell when I ``set B=b'' and ``set
> b=B'' what remains is B=B.  If I reverse the order of the set commands,
> assuming neither B or b is a valid variable at the time, what remains is
> b=b.  This environment variable quackery becomes even more burdonsome if
> one makes use of the C runtime _environ pointer.  And even worse is the
> envp argument to the main function, according to MSDN the variable may not
> contain the correct data in all cases.

So this means that whoever writes Makefiles for Windows (or Makefiles
that should be portable to Windows) should be careful about variables
that differ only in letter case.  FWIW, I don't think I've seen any
Makefiles that have such variables, but perhaps I misremember.  In any
case, Make itself does not have to solve all such problems, only those
that can adversely affect Make's own operation.  And I think Path is
the only variable that belongs to that category.  Maybe we should also
add to this variables that are internal to Make: MAKE, MAKEFLAGS,
MAKEFILES, MAKEFILE_LIST.

> Uppercasing the variable name helps avoid confusion and possibly reduce
> list noise.

I don't recall too many messages on this list about problems related
to environment variables, with the exception on Path.

> We could replace getenv() and setenv() with our own versions that
> read and write the _environ variable directly.

This is possible, but can we do this reliably?  That is, are getenv
and setenv purely application code in the libraries used by MinGW, or
do they involve some OS interaction?  If the latter, there's a
possibility that the OS does something that will preclude what you
want.  (Cygwin replaces the MS runtime libraries, unlike MinGW, so
Cygwin might be able to do more magic than MinGW.)