Allow defining environment variables for the launched application

[albel727]

It would be great, if one could have e.g. "env": { "variable1" : "value1" } section in launch.json at least for "request": "launch" kind of debugging, so that environment variables could be specified for the launched process to be debugged.

It's a dealbreaker to not have this capability, because I need to change env-vars very often during development. In particular, Rust executables love to depend on RUST_LOG, RUST_BACKTRACE and suchlike variables for debug-related output setup, which needs to be changed as often as from run to run sometimes.

[albel727]

I'm afraid your implementation completely wipes all environment variables except those specified in config. Including $HOME, $PATH and the rest of very useful and necessary stuff. Normally they're inherited, i.e. you're supposed to merge new settings on top of process.env.

[WebFreak001]

it does indeed do that, though how would you otherwise unset environment variables from the launch config?

[albel727]

Well, something like { "VARNAME": null } syntax could be supported to denote variables that should be unset instead of being inherited or set to something else.

But the most pressing matter here is that unsetting all variables is rarely ever needed, and all those very important variables, like $HOME (absence of which prevents gdb from reading user's .gdbinit, for instance), or $LANG (absence of which does "wonders" to user's display and screws hard over gdb's python-based pretty printers, which begin to fail with UnicodeEncodeError and such, making things undebuggable) are really better returned as soon as possible, even if at the price of reverting this commit.

[WebFreak001]

hm ok I can change the behaviour to extend the processes environment

[albel727]

That would be most sweet. Sorry for bothering you, I should've been more specific from the start.

[WebFreak001]

ok new release is pushed

[albel727]

Great, works as expected. Thanks!