Closed BobbyAnguelov closed 3 years ago
Nice find! I'll have a look.
Can I check - did you run it with subprocess_option_inherit_environment
?
I just called it as follows:
subprocess_create( processCommandLineArgs, subprocess_option_combined_stdout_stderr, &m_subProcess );
No other options.
Looking at the code again, I probably should have used the option: subprocess_option_inherit_environment 🤦
Ah I think this is by design then.
If you don't have subprocess_option_inherit_environment
set and environment
is NULL, it'll launch the process with an empty environment.
yup, me being an idiot is definitely by design...
Might be good to add it to examples/readme. I completely missed it the first time round and assume it would do the same as the CreateProcess i.e. inherit environment by default.
Aye I'll add some extra docs, good idea!
I was having an issue where starting a process via you lib was failing in a strange way. After debugging I realized that there is a subtle bug in how you call CreateProcessA. By default you do this:
char *used_environment = SUBPROCESS_NULL;
Which is then fed into the CreateProcessFunction, except instead of it receiving a nullptr, it receives a valid ptr to an empty string. This breaks the semantics so ends up running the process with an empty environment instead of using the inherited environment.
I hacked it as follows just to get it to work, but I'm not entirely sure what the idiomatic c way to that is (I'm mostly a c++ prog).
I did this at the CreateProcessA callsite:
( used_environment[0] == SUBPROCESS_NULL ) ? SUBPROCESS_NULL : used_environment