2

In node/io.js, by default, calling child_process.exec() causes the child process to inherit all of the environment variables of the parent process. As I understand it, this is normal behavior for Windows' CreateProcess function.

However, this is problematic for me as the parent process (Atom) by default sets NODE_ENV to production, which, when leaked to child processes (e.g. a terminal app), causes obscure, sometimes serious problems downstream.

The only two possible solutions I can think of are setting the env key of exec()'s options argument to either:

  1. An empty object. This causes the child process to receive a fresh set of system environment variables. The problem with this is that any user-specific environment variables are lost, e.g. APPDATA, resulting in even more problems downstream.
  2. A copy of process.env where the offending variables are removed or modified as necessary. Works, but no way to know what the previous values of these variables were, so could very well be clobbering the original values anyways.

Is there a way in node/io.js to ensure that child processes do not inherit their parent's environment variables, but still have all of the current user's environment variables (e.g. APPDATA)?

Running under Atom 1.0.2's embedded io.js (1.5.1), Windows 7 SP1 64-bit.

blah238
  • 1,796
  • 2
  • 18
  • 51
  • Can you not just take your current environment and filter out the things you don't want to pass to the child and pass that as the environment to `.exec()`? – jfriend00 Jul 22 '15 at 02:20
  • @jfriend00 That would be option 2 which I mentioned also has downsides. – blah238 Jul 22 '15 at 02:21
  • There is no "default" value of the environment. What you get passed to your parent nodejs as the environment is what you know. There isn't another environment to know. Where do you expect to get some other environment? – jfriend00 Jul 22 '15 at 02:22
  • I would expect there to be away to start a child process with all of the system and user environment variables you would get if you were to start a process manually, e.g. by opening up a command prompt and typing in a command. [`start /i`](https://technet.microsoft.com/en-us/library/Cc770297.aspx) looked promising but in the end it still inherited Atom's environment. – blah238 Jul 22 '15 at 02:25
  • 1
    @jfriend00: actually there is an unambiguous default value; the environment block returned by the CreateEnvironmentBlock API function. (The web interface to the io.js repository doesn't seem to be willing to show me the code for child_process, but my guess is that there's no way to do this from node.js.) – Harry Johnston Jul 22 '15 at 03:05
  • If you don't have to do this from within node.js, it would be fairly straightforward to implement a "run this with the default environment" application in C. – Harry Johnston Jul 22 '15 at 03:06
  • @HarryJohnston - probably it is not in node.js because it's Windows-specific. If one was willing to sacrifice x-platform-ness, a binding could be written for any particular Windows API call. – jfriend00 Jul 22 '15 at 03:07
  • @HarryJohnston Interesting -- is there a way to call WinAPI functions through node.js without having to write a C program? This is for a Windows-only Atom package so no worries about cross-platform support. [`node-ffi`](https://github.com/node-ffi/node-ffi) looks promising. – blah238 Jul 22 '15 at 03:47
  • I have no idea, but @jfriend00 might know. – Harry Johnston Jul 22 '15 at 04:08
  • 1
    I've not used this myself, but there is a sort of generic binding tool for Windows API without writing your own platform code: [Create a node.js native extension on Windows](http://stackoverflow.com/questions/9624536/create-a-node-js-native-extension-on-windows). – jfriend00 Jul 22 '15 at 04:26

0 Answers0