Environment variables (PATH etc.) not set in Visual Studio Code development container (IDFGH-13713)

[TheSeven]

This recent addition of code

esp-idf/tools/export_utils/shell_types.py

Line 125 in 3c99557

fd.write(f'source {bashrc_path}\n')

causes an endless loop of ~/.bashrc sourcing /opt/esp/idf/export.py, running activate.py, activate_venv.py and the resulting script in turn sourcing ~/.bashrc again.
VSCode waits for 10 seconds for this to finish, which it doesn't, then gives up and continues without the necessary environment variables being set, resulting in builds failing with xtensa-esp32-elf-gcc not being found.

[mfialaf]

Hi @TheSeven , thank you for reporting the bug.

As for now, I can recommend a temporary workaround, by using the old export script:
ESP_IDF_LEGACY_EXPORT=1 . ./export.sh or . ./tools/legacy_exports/export_legacy.sh

[TheSeven]

I worked around it by just breaking the recursion in .bashrc by changing the related line in the Dockerfile to this:
RUN echo "[ -z \"\$ESP_EXPORT_DONE\" ] && ESP_EXPORT_DONE=yes . /opt/esp/idf/export.sh > /dev/null 2>&1" >> ~/.bashrc

With that file being automatically generated by the ESP-IDF VSCode extension, should I open an issue against that to get a workaround added there for the time being?

[fhrbata]

I worked around it by just breaking the recursion in .bashrc by changing the related line in the Dockerfile to this: RUN echo "[ -z \"\$ESP_EXPORT_DONE\" ] && ESP_EXPORT_DONE=yes . /opt/esp/idf/export.sh > /dev/null 2>&1" >> ~/.bashrc

With that file being automatically generated by the ESP-IDF VSCode extension, should I open an issue against that to get a workaround added there for the time being?

Apologies for the inconvenience. I believe this issue needs to be addressed in the export scripts. At present, the export script is sourcing .bashrc, which is incorrect.