Bug 1004 – Changed environment not passed to child process

/* Bug in spawnvp (and maybe others): Only the initial environment is copied to the child process, modifications get lost Compile and run, type "SET", you should see a line YYY=xxxx but you don't. Works fine with gdc -mno-cygwin, so I guess it is a phobos bug. */ import std.process; extern(Windows) void SetEnvironmentVariableA(char *lpName, char *lpValue); int main(char[][] args){ SetEnvironmentVariableA(toStringz("YYY"),toStringz("xxxx")); return spawnvp(0,"cmd.exe",args); } I did not find guidelines for setting values for Priority, "Assign To", and "Cc", so sorry for bothering everyone...

These two versions work for me, someone with a way better knowledge of D may optimize the clumsy version of spawnvp int spawnvpe(int mode, char[] pathname, char[][]argv, char[][] envi){ char** argv_ = cast(char**)alloca((char*).sizeof * (1 + argv.length)); char** envi_ = cast(char**)alloca((char*).sizeof * (1 + envi.length)); toAStringz(argv, argv_); toAStringz(envi, envi_); return std.c.process.spawnvpe(mode, toStringz(pathname), argv_, envi_ ); } int spawnvp(int mode, char[] pathname, char[][] argv){ char** argv_ = cast(char**)alloca((char*).sizeof * (1 + argv.length)); toAStringz(argv, argv_); char[][] env; char *eBase=cast(char *)GetEnvironmentStringsA(); for(char *str=eBase; *str; ++str){ int slen = std.string.strlen(str); env.length = env.length+1; env[env.length-1].length = slen; size_t i = 0; while(*str){ env[env.length-1][i++]= *str++; } } char** env_ = cast(char**)alloca((char*).sizeof * (1 + env.length)); toAStringz(env, env_); FreeEnvironmentStringsA(cast(char **)eBase); return std.c.process.spawnvpe(mode, toStringz(pathname), argv_, env_ ); }

Does not happen with spawn's successor, spawnProcess.

I wonder if this should be reopened or at least closed as wontfix, since this is a D1 bug?

Sorry, I didn't know D1 bugs shouldn't be closed. I have closed a few bugs with the false assumption that since D1 is deprecated, these bugs will never be fixed.

It wasn't so much an instruction as an observation :) I think the appropriate thing might be to close all D1 bugs as wontfix. But I think to close it because it's fixed in D2 gives the wrong impression. Again, that's an observation, I wonder what others think about this.

> But I think to close it because it's fixed in D2 gives the wrong impression. Sorry about that. Since this bug was created before D2 existed, and since it's reasonable to expect that most D1 users will migrate to D2, and since the relevant Phobos module is a direct ancestor to the D1 version, I think it's OK to say that this issue was resolved in the latest version of D. However I'm not sure if the same applies to the other issues I've closed.

I think we've given up on everything except wrong-code and compiler crashes for D1. Even if some people are using D1, they most likely aren't using phobos, and AFAIK nobody is patching it. I'd say just close this and similar bugs as FIXED.

(In reply to comment #7) > I'd say just close this and similar bugs as FIXED. I think resolved as wontfix is a more accurate statement, because if for any reason someone using D1 has the same issue and searches for it, it gives the impression that the issue is fixed in some way for D1. I've done that here. If people think this is not the right course, I'm very much not attached to this, it just seems the correct action to me.

D1 is still in use. Just ignore D1 only bugs if you don't use D1. But to close them does a disservice to the existing D1 users.

(In reply to comment #9) > D1 is still in use. Just ignore D1 only bugs if you don't use D1. But to close > them does a disservice to the existing D1 users. Walter, where do we draw the line? D1 is officially discontinued, when will we really stop supporting it?

Does this apply equally to the compiler and Phobos? Although there is still lots of recent activity in the D1 compiler branch, the last commit on the Phobos D1 branch is almost a year ago.

(In reply to comment #11) > Does this apply equally to the compiler and Phobos? Although there is still > lots of recent activity in the D1 compiler branch, the last commit on the > Phobos D1 branch is almost a year ago. The D1 compiler activity is 99% Walter backporting D2 wrong code/ICE fixes.

(In reply to comment #10) > D1 is officially discontinued, when will we > really stop supporting it? Well, "we" aren't supporting it. I and Sociomantic are, and we do it because Sociomantic is heavily dependent on it. Sociomantic is a valued contributor to the D community, and I see no reason to throw them under the bus.

(In reply to comment #13) > Well, "we" aren't supporting it. I and Sociomantic are, and we do it because > Sociomantic is heavily dependent on it. Sociomantic is a valued contributor to > the D community, and I see no reason to throw them under the bus. Sure, it only affects the rest of us through noise in the bug reports and commit emails, and I assume it complicates changelog generation, due to the inconsistent bugzilla 'Version' tagging I can't simply filter out all D1 bugs. Just mildly annoying. So just to spell it out, all D1 activity will stop if/when sociomantic moves completely to D2? And are sociomantic actually using phobos1 or are you speculating? I don't want to repeat the recent situation where you said interpret.c had to be kept D1-compatible, with Don eventually clarifying that it did not and had not been for some time. I assume we/you won't be maintaining phobos1 if sociomantic aren't actually using it.

Don has stated on the newsgroup that Sociomantic is not using D1 phobos, and it is ok to close these.