nRF Connect for VS Code messes up environment variables

[JonasJ]

Hi,

I have an environment variable with newlines and that is messed up by the VS Code extension. It seems that the extension tries to parse and rewrite the whole environment for some unknown reason. I have the following variables defined among others.

BASH_FUNC_ml%%=() { module ml "$@"
}
BASH_FUNC_which%%=() { ( alias;
 eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot $@
}

When I build inside VS Code i get the following in the terminal.

[301/301] Generating zephyr/merged.hex
/bin/sh: ml: line 1: syntax error: unexpected end of file
/bin/sh: error importing function definition for `ml'
/bin/sh: which: line 1: syntax error: unexpected end of file
/bin/sh: error importing function definition for `which'

nRF Connect SDK extension for VS Code, v2022.7.242.

Why does the extension rewrite my environment in the first place?

Sigurd Hellesvik Thanks for reminding me to post this issue here.

[JonasJ]

Hi,

VS Code correctly inherits the environment variables, no issue there. If you try to build a project using nRF Connect SDK Extension I get the errors in my post.

I assume this is because the nRF extension for VS Code reads the existing env variables but can't handle those that have newline (\n) in them and thus creates a broken env when launching the terminal to run west build.

Thanks.

[JonasJ]

Hi,

You can test this you self by sourcing the following file in a shell and launch vscode after that. You should see an error similar to my report.

foo_bar() {
    echo "This is a function in bash"
}

export -f foo_bar

I'm running Fedora 36 and it doesn't matter which project I build.

[Håkon Alseth]

Hi,

 

Yes, I can confirm that there can be issues with local environment on different linux distro's, as we mainly target ubuntu.

I have made the nrf VScode team aware of your issue, and it will be evaluated for future improvements.

 

As a workaround, can you try to check for $NRF_CONNECT_VSCODE to work around this issue?

More details can be found here in our documentation: https://nrfconnect.github.io/vscode-nrf-connect/connect/west.html#controlling-the-west-environment

 

Kind regards,

Håkon

[JonasJ]

Thanks.

These environment variables are set in system files so it's not something I'd like to mess around in. But thanks for sharing that part of the documentation, didn't know about that variable. Can be useful.

I hope the VS Code team can figure out what is wrong. It doesn't stop med from compiling but it generates annoying noise in the terminal when build.

At the end of that documentation I found this. Not sure that I understand this correctly. VS Code reads .profile but if I want to disable that feature I should set things i .profile?

Is this paragraph really correct?

VS Code picks up environment variables set in .profile. To disable this option while still being compatible with the terminal, move the nRF Connect SDK-specific environment variables (such as ZEPHYR_TOOLCHAIN_VARIANT or GNUARMEMB_TOOLCHAIN_PATH) to .profile.

[Håkon Alseth]

Hi,

 

JonasJ said:

At the end of that documentation I found this. Not sure that I understand this correctly. VS Code reads .profile but if I want to disable that feature I should set things i .profile?

Is this paragraph really correct?

I understand the confusion here, I'll try to explain a bit about the background of how it became this way.

Former versions of NCS/zephyr stated that you shall use environmental vars as a part of the getting started for the linux platform, similar to what is still documented for "west": https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.2/zephyr/develop/getting_started/index.html#get-zephyr-and-install-python-dependencies

But, it also stated that the toolchain and so forth should be placed in the local environment.

We had to pick these up with VSCode, which meant that we needed to parse the local env setup to pick them out, which per the above has been .bashrc. So, to avoid that it parses more than it should, you can move it one step up, ie. in .profile.

 

Kind regards,

Håkon