> Date: Wed, 02 Mar 2005 17:04:48 +0100 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > > 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. _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
