Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 9, signal null) · Issue #154410

相关文章推荐

沉稳的草稿本 · 2019国际学生手册（本科生）-上海大学信息公开网· 1 月前 ·

胆小的冰淇淋 · 小孩开大车番外篇，冲儿与不疑意料之中的截胡者 ...· 4 月前 ·

重情义的鸵鸟 · Microsoft SQL server ...· 7 月前 ·

会开车的蘑菇 · 小米12智能手机评测--一个紧凑而强大的高级 ...· 11 月前 ·

腼腆的针织衫 · Visual Studio 2019 ...· 1 年前 ·

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 9, signal null) #154410 Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 9, signal null) #154410 kirvedx opened this issue Jul 7, 2022 · 3 comments

Steps to Reproduce:

Using the following


    ~/.bashrc

, add the last export for resolving some issues with


    node v18

(i.e.


    NODE_OPTIONS=--no-experimental-fetching

rik@devrikx:~$ cat ~/.bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
  *i*) ;;
    *) return;;
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar
# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
  debian_chroot=$(cat /etc/debian_chroot)
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
  xterm-color|*-256color) color_prompt=yes;;
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
  if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
  # We have color support; assume it's compliant with Ecma-48
  # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
  # a case would tend to support setf rather than setaf.)
  color_prompt=yes
  color_prompt=
if [ "$color_prompt" = yes ]; then
  PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
  PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
unset color_prompt force_color_prompt
# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
  PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
  test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
  alias ls='ls --color=auto'
  #alias dir='dir --color=auto'
  #alias vdir='vdir --color=auto'
  #alias grep='grep --color=auto'
  #alias fgrep='fgrep --color=auto'
  #alias egrep='egrep --color=auto'
# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
  . ~/.bash_aliases
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
  . /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
  . /etc/bash_completion
# Add the GPG key to our profile
export GPG_TTY=$(tty)
# Modify the path variable to contain paths to executables we'd like
# added
# Set the npm global path (prepend it so its found first!)
NPM_PACKAGES="${HOME}/.npm-global"
export PATH=$NPM_PACKAGES/bin:$PATH
# Preserve MANPATH if you already defined it somewhere in your config.
# Otherwise, fall back to `manpath` so we can inherit from `/etc/manpath`.
export MANPATH="${MANPATH-$(manpath)}:$NPM_PACKAGES/share/man"
# Set the android-studio binaries path
export PATH=$PATH:/opt/android-studio-canary/bin
export PATH=$PATH:/opt/android-studio/bin
# Set the android-studio platform tools path
export PATH=$PATH:~/Android/Sdk/platform-tools
#export PATH=$PATH:~/Android/Sdk/platform-tools
# Set the android-studio tools path (don't really need these from terminal)
# export PATH=$PATH:~/Android/Sdk/tools/bin
# Set the GOPATH
export PATH=$PATH:/usr/local/go/bin
export PATH=$PATH:/home/rik/go/bin
# Fix some issues with Node.js v18 while we wait for resolution:
# (Added 6-2022, after there was an error trying to build @kwaeri/filesystem module)
export NODE_OPTIONS=--no-experimental-fetch

Start Visual Studio Code in Gnome DE, leveraging the gui icon (either from panel or favorites):


    /usr/share/code/code --unity-launch %F

Useful Information:

The only other thing I can think of, is that at one point in time I did take some steps to try and change the terminal that was opened by opening terminal to a directory from nautilus (file-roller), from gnome-terminal to terminology.

None of the steps did manage to make that happen:

Using update-alternatives :

Using dconf configuration:

gsettings set org.gnome.desktop.default-applications.terminal exec /usr/bin/terminology
gsettings set org.gnome.desktop.default-applications.terminal exec-arg "--current-directory"

Using nautilus-configuration-tool

Using filemanager-actions

However, none worked - so I've put (1) back to gnome-terminal , undone the steps in (2), and uninstalled both (3) and (4).

The issue has started since last update after I updated Node.js from 16 (LTS) to 18, and added the NODE_OPTIONS fix ( --no-experimental-fetch ).

System Information:

Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz (12 x 1300) GPU Status 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled Load (avg) 0, 0, 0 Memory (System) 62.72GB (48.43GB free) Process Argv --unity-launch Screen Reader

Enabled Extensions

Extension Author (truncated) Version

Which runs something close to:

$SHELL -ilc "'<vscode binary path>' --ms-enable-electron-run-as-node -p 'JSON.stringify(process.env)'"

Does removing the --no-experimental-fetch thing fix it? Changes to NODE_OPTIONS will affect the command above.

It does fix it, but that's unfortunate because on Node v18 (at least for now) several modules aren't building when leveraging the latest module versions - with the following error:

Which requires me to either export NODE_OPTIONS=--no-experimental-fetch with a follow-up unset NODE_OPTIONS to resolve issues for a successful build in the terminals within vscode - or in an external one. Then I'm chasing build paths in terminals (I'm working on 40+ modules at a time) and as you can imagine it's a menial nuance, and if I can avoid it I'd like to.

I tried to change my ~/.bashrc entry to:

# ...
# Set no experimental fetching for resolving node v18 issues:
export NODE_OPTIONS="$NODE_OPTIONS --no-experimental-fetch"

So as not to unset options that vscode might be setting, but that did not resolve the error. Is that not going to be something that can be avoided? According to the official docs :

Options from the command line take precedence over options passed through the NODE_OPTIONS environment variable.

From what you've referenced, I'm not sure whether the code - or ms flags even - are triggering an export of NODE_OPTIONS in the background, or doing so via the command line - either of which should overwrite my setting and function properly.

So, what I'm currently doing to avoid the nuance of exporting it - is baking it into the npm script that lives in each project's package.json :

"scripts" : { "build" : " gulp clean && NODE_OPTIONS=--no-experimental-fetch gulp " ,

It's not the end of the world, just nuanced to a degree; At this point the nuance is having to remember to remove that when committing changes to the file - or having to commit a removal later on. The option is only necessary until issues are resolved with the modules effected on Node v18

This is just how NODE_OPTIONS works, it overrides options for any node instance that gets run, and that includes VS Code. The approach I'd take here is to set NODE_OPTIONS conditionally depending on what the purpose of the shell is being run is. For example you could do this:

if [ "$TERM_PROGRAM" == "vscode" ]; then export NODE_OPTIONS="$NODE_OPTIONS --no-experimental-fetch"

That will set it only when running in VS Code's terminal, this won't work for other terminals of course but it should fix the problem of VS Code's environment being tampered with.