On Sun, Feb 17, 2013 at 1:59 PM, John W. Eaton <j...@octave.org> wrote:
> On 02/15/2013 03:16 PM, Michael Goffioul wrote: > >> On Fri, Feb 15, 2013 at 2:10 PM, Paul Eggert <egg...@cs.ucla.edu >> <mailto:egg...@cs.ucla.edu>> wrote: >> >> On 02/15/2013 07:10 AM, Michael Goffioul wrote: >> > I guess the only solution to this problem is to always _putenv >> and not manipulate "environ" directly. >> >> Thanks, is that something you can write and contribute >> to the GNU project? This sort of thing really requires >> Microsoft expertise, which I don't have. >> >> >> I can give it a try, but not before a couple of days. Also to avoid >> breaking things, what is the putenv module supposed to solve? From what >> I understand, it is: >> - make putenv("VARNAME") remove VARNAME from the environment >> - make putenv("VARNAME=") create and empty environment variable >> Is there anything else? >> >> Reading the specs here [1], I don't think the bit: "In either case, the >> string pointed to by /string/ shall become part of the environment, so >> >> altering the string shall change the environment." is actually possible. >> I believe _putenv ultimately calls SetEnvironmentVariable [2] and >> nothing there says that altering the given string will effectively alter >> the environment. >> >> Michael. >> >> [1] http://pubs.opengroup.org/**onlinepubs/9699919799/** >> functions/putenv.html<http://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html> >> [2] >> http://msdn.microsoft.com/en-**us/library/windows/desktop/** >> ms686206(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/ms686206(v=vs.85).aspx> >> > > How about something like the attached patch? The program I used for > testing (modified from Michael's, and with the modified putenv function > included) is also attached. > > I'm not sure I like the way I've nested the conditionals, or if it is even > the right thing to do. Maybe it would be better to leave the original code > as it was and just have a separate version for Windows systems that uses > _putenv and SetEnvironmentVariable. I'm willing to rework this as > necessary. > THe situation is a bit messy, because of the manipulation of the environment at 2 different levels (C runtime and Win32). You have _putenv, environ and SetEnvironmentVariable. _putenv will update environ and call SetEnvironmentVariable. Manipulating environ has no effect at Win32 level. And I believe SetEnvironmentVariable will not update environ. When putting everything together, I think the best trade-off is to use always _putenv, and covering the cases of putenv("VAR") and putenv("VAR=") (if possible). > > In any case, I think it is important to fix putenv so that we not have to > do some tricks at the time of subprocess creation in order for the > environment to be passed to subprocesses. Relying on that is likely to > lead to unexpected results and problems that are hard to debug. I think it > is unreasonable to expect that we can control the way all subprocesses are > created. Agreed. Michael.
