starship: Shell does not work after upgrading with Homebrew

Current Behavior

brew upgrade
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
rubyfmt
==> Updated Formulae
starship ✔  clp         composer    erlang@21   hugo        protobuf    ungit
cfn-lint    coinutils   erlang      gitmoji     paket       syncthing

==> Upgrading 1 outdated package:
starship 0.33.1 -> 0.34.1
==> Upgrading starship
==> Downloading https://linuxbrew.bintray.com/bottles/starship-0.34.1.x86_64_linux.bottl
==> Downloading from https://akamai.bintray.com/bb/bba0c68907b0ef7d3cbc08c307d9ff45a659a
######################################################################## 100.0%
==> Pouring starship-0.34.1.x86_64_linux.bottle.tar.gz
🍺  /home/linuxbrew/.linuxbrew/Cellar/starship/0.34.1: 7 files, 5.7MB
Removing: /home/linuxbrew/.linuxbrew/Cellar/starship/0.33.1... (6 files, 7.5MB)
Removing: /home/thedrow/.cache/Homebrew/starship--0.33.1.tar.gz... (4.9MB)
==> Checking for dependents of upgraded formulae...
==> No dependents found!
bash: /home/linuxbrew/.linuxbrew/Cellar/starship/0.33.1/bin/starship: No such file or directory
bash: /home/linuxbrew/.linuxbrew/Cellar/starship/0.33.1/bin/starship: No such file or directory

bash: /home/linuxbrew/.linuxbrew/Cellar/starship/0.33.1/bin/starship: No such file or directory
bash: /home/linuxbrew/.linuxbrew/Cellar/starship/0.33.1/bin/starship: No such file or directory

No further commands can be inputted since the previous executable was removed.

Expected Behavior

The shell should continue to function until it is closed.

Additional context/Screenshots

None

Possible Solution

None

Environment

  • Starship version: 0.34.1
  • bash version: GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu) Copyright © 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

  • Operating system: Ubuntu 18.04
  • Terminal emulator: Alacritty 0.4.1

Relevant Shell Configuration

# ~/.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;;
esac

# 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)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# 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
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
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"
    ;;
*)
    ;;
esac

# 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'
fi

# 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 -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# 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
fi

# 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
  fi
fi
export PATH="/home/linuxbrew/.linuxbrew/bin:$PATH"
export MANPATH="/home/linuxbrew/.linuxbrew/share/man:$MANPATH"
export INFOPATH="/home/linuxbrew/.linuxbrew/share/info:$INFOPATH"

eval "$(pyenv init -)"
export EDITOR=nano

# added by travis gem
[ -f /home/thedrow/.travis/travis.sh ] && source /home/thedrow/.travis/travis.sh

pyenv virtualenvwrapper_lazy
export PATH="$HOME/.cargo/bin:$PATH"

export PATH="/home/linuxbrew/.linuxbrew/sbin:$PATH"
eval "$(hub alias -s)"
export NVM_DIR="$HOME/.nvm"
  [ -s "/home/linuxbrew/.linuxbrew/opt/nvm/nvm.sh" ] && . "/home/linuxbrew/.linuxbrew/opt/nvm/nvm.sh"  # This loads nvm
  [ -s "/home/linuxbrew/.linuxbrew/opt/nvm/etc/bash_completion.d/nvm" ] && . "/home/linuxbrew/.linuxbrew/opt/nvm/etc/bash_completion.d/nvm"

eval "$(starship init bash)"
eval $(thefuck --alias)

Starship Configuration

<unknown config>

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 16 (11 by maintainers)

Commits related to this issue

Most upvoted comments

@chipbuster How would you feel about adding the which crate as a dependency? I’m not wild about a new dependency, but this one seems pretty small and does exactly what we’re looking for, including support for Windows. I have it working locally (Linux) and it’s finding the Homebrew symlinked binary.

Just noticed this now but we added the which crate in an unrelated change so this might fix is even easier to add now.

You could execute brew --prefix and concat /bin/starship to it. That should work on Homebrew.

Which brings me to the following question, could it be solved by altering shell profile:

# old
eval "$(starship init bash)"
# new
eval "$($(brew --prefix)/bin/starship init bash)"

@chipbuster A few options I can think of are:

  • Check each PATH component
  • Shell out to which
  • Maybe using execlp/execvp, if what you really need to do is exec starship and not necessarily get the command’s path. You could also do /bin/sh -c, which should be fairly portable on POSIX systems.

If any of these options is appealing, I can take a pass at implementing it.

This would work, but putting dependence on the installation method into the binary itself seems like an anti-pattern. It also wouldn’t work for other managers like nix.

@bbigras Are you aware of anything like this happening during NixOS upgrades?

Okay, so I’m fairly certain this is caused when we call current_exe() to get the path to the starship executable. It’s resolving the physical path instead of the logical one, which isn’t great.

Unfortunately, I don’t know of a standard way to get the logical path to the starship executable: current_exe can’t offer any guarantees about its behavior because the underlying OSses sometimes don’t offer the tools to guarantee certain behaviors.

As it stands now, I don’t see an obvious way to 100% fix this problem. We can’t read out of args[0] because that usually doesn’t contain the full logical path of the program. I suppose we could try parsing PATH and doing the search ourselves to find the logical path, but that seems like a solution that could break in unpleasant ways (and I don’t even know if ion/pwsh support this).

which -a starship:

/home/linuxbrew/.linuxbrew/bin/starship
/home/linuxbrew/.linuxbrew/bin/starship

echo $PATH:

/home/thedrow/.nvm/versions/node/v13.7.0/bin:/home/linuxbrew/.linuxbrew/sbin:/home/thedrow/.cargo/bin:/home/thedrow/.pyenv/shims:/home/linuxbrew/.linuxbrew/bin:/home/thedrow/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin