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

[Eli Zaretskii]

> Date: Wed, 02 Mar 2005 17:04:48 +0100
> From: Alessandro Vesely <address@hidden>
> 
> > One caveat is that you must take care with PATH and Path 
> > to ensure that no unintended user environment creeps into the path
> > unless you desire this to happen. To ensure that PATH/Path are set as
> > you want, you should set the values in your global make configuration
> > so that all sub-makes and sub-shells get the value of PATH and Path
> > that  you expect. Note I only mention PATH vs Path because of
> > the way that Bourne shell implementations will usually want PATH 
> > to be set whereas Win32 systems are happy with virtually any 
> > spelling as Win32 does not know the difference.
> 
> The latter statement is not fully correct, since win9x is not happy.

That's because Windows 9x uses PATH, not Path.  The latter is the
invention of the NT family of Windows versions (W2K, XP, W2003, etc.).

> `strings sh.exe | grep Path' didn't yield anything, so I guess the
> former statement is true also for MinGW's sh.exe, i.e. it doesn't
> treat "Path" specially.

Bash uses PATH, of course.  But it strikes me as a grave bug of the
MinGW port of Bash that it doesn't convert Path to PATH, because Unix
shell scripts use PATH, and will choke if it's not found.  Too bad we
need to cope with such a port.

> Thus, it looks like `Path' is needed to avoid _contaminating_ the Windows
> setup with unixy stuff.

I don't understand.  Didn't somebody (you?) say that Windows
environment is case-insensitive, and that the standard C library
function `getenv' will find both Path and PATH?  If so, it sounds like
exporting just PATH to the subsidiary programs will do, as both Bash
and other Windows programs will be happy.  Am I missing something?

> I don't include the brutal patch, because it's brutal.

What does it do? push only PATH into the environment?  If so, I think
it's what we need.