Explicitly set shell type in export.sh for bash and zsh
-Most of the issues reported with the updated export scripts are related
to shell detection. Since we already know the shell type for commonly
used ones like bash or zsh, we can pass the shell type directly to the
activate script. This should hopefully resolve the shell detection
problems for most users.
This update also modifies the shell type detection to rely solely on
psutil.Process().cmdline() rather than psutil.Process().exe(). This
change aims to resolve permission issues that may occur if, for example,
the Python binary has certain capabilities assigned.
Move shell completion to the init script
- Currently we are expanding the autocompletion in the activate script and
adding the expanded commands into the init script. To avoid
concerns about shell versions, move the entire expansion to the init
script.
This feature serves as an immediate fix in case
the new export approach causes issues.
The user can simply set the environment variable `ESP_IDF_LEGACY_EXPORT`,
and the old export script will be used.
Esptool.py is available from the esptool package which is installed in
every ESP-IDF v5.0+ shells. Therefore, the path to the legacy wrapper
scripts is not needed to be in the PATH. In some cases like
https://github.com/espressif/esp-idf/issues/10926 it even cases problem
because the wrapper doesn't have a shebang line and is not executable.
Note that the wrapper is kept only for invoking esptool as "python
$IDF_PATH/..../esptool.py" which was previously used mostly in CMake
files. There should be no other use-case where the esptool wrappers are
still needed.
I the shell has `set -u` (to abort on unbound variable), sourcing
export.sh currently fails when IDF_EXPORT_QUIET or IDF_PATH is not set:
> /path/to/esp-idf/export.sh:16: IDF_EXPORT_QUIET: unbound variable
This commit sets a default empty value to those variable, as done
in 16731833fb (which forgot IDF_PATH as it's usually set, the other
variable landed later in the file).
In the latest release of macOS (and probable some other recent *nixes as well?) `python` is no longer available by default, only `python3`. This causes `export.sh` to fail as it still had a reference to plain `python`. This now works as expected.
Merges https://github.com/espressif/esp-idf/pull/9749
In failure cases, when idf_export_main() returns 1 (failure),
the export.sh script returns 0 (success). This makes it very
difficult to detect failure when writing scripts that use
export.sh. Furthermore, idf_export_main() does not clean up all
internal variables and functions in failure cases.
Move all cleanup steps into a cleanup function and pass
the return value from idf_export_main() to the cleanup
function so it can return with that same return value.
Signed-off-by: Marek Fiala <marek.fiala@espressif.com>
Closes https://github.com/espressif/esp-idf/pull/5744
