Repository navigation
child_process.exec considering process.env improvement #11861
Description
- Version: At least from 4.8.0 up to 6.10.0
- Platform: debian 8
- Subsystem: lib/child_process.js
var exec = require('child_process').exec;
var options = {
env : {
NODE_ENV : 'production'
}
};
exec(command, options, function(err, stdout, stderr) {
//do something here
});The above will loose all other process.env variables.
This might be correct behavior, but on the other hand I personally would have expected that exec does internally something like:
var env;
if (options.env){
env = Object.assign({}, process.env, options.env);
} else {
env = Object.assign({}, process.env);
}and then using it further on. This makes every child process having the process.env with possibility to override specific env vars. I am not familiar with use cases or what other developers would expect, but at least the above way drops out that logic from customer apps and could feel comfortable.
Suppressing that with options.env = false could be an idea too.
So don't understand this as a reported bug, just an improvement idea you might think about.
Thanks!
Activity
bnoordhuis commentedon Mar 15, 2017
Thanks for the suggestion but the problem with that approach is that you can't specify a fully custom environment, you can't avoid inheriting from the existing environment.
As well, backwards compatibility is an issue. The current behavior has been around for a long time, changing it now would probably be quite disruptive to the ecosystem.
cjihrig commentedon Mar 15, 2017
Yes, what Ben said. The only option would be another setting like
appendEnvor something, but the existing workaround doesn't seem too difficult. The hardest part is remembering that you have to do it (I've been bitten by this before too). I'm going to close the issue as a "won't fix."KaiSchwarz-cnic commentedon Mar 15, 2017
No fear, I understand these reasons, I've basically expected this response. Thanks that you both had an eye on it.