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
- Favor finding Starship on the PATH over its absolute path on disk. (#910) — committed to nirvdrum/starship by nirvdrum 4 years ago
- Favor finding Starship on the PATH over its absolute path on disk. (#910) — committed to nirvdrum/starship by chipbuster 2 years ago
Just noticed this now but we added the which crate in an unrelated change so this might fix is even easier to add now.
Which brings me to the following question, could it be solved by altering shell profile:
@chipbuster A few options I can think of are:
PATHcomponentwhichexeclp/execvp, if what you really need to do is execstarshipand 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
PATHand 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:echo $PATH: