Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

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

Breaks gnome-terminal new window/tab with same workdir functionality #327

Closed
frenkel opened this issue Sep 9, 2019 · 4 comments
Closed
Labels
🐛 bug Something isn't working as expected.

Comments

@frenkel
Copy link

frenkel commented Sep 9, 2019

Bug Report

Current Behavior

When starship is added to a default bashrc on Fedora (and probably others), pressing CTRL+SHIFT+T or CTRL+SHIFT+N doesn't open a new tab or window with the same working directory. Instead it starts in ~.

Expected Behavior

Open the tab or window in the same working directory.

Additional context/Screenshots

https://wiki.gnome.org/Apps/Terminal/FAQ#How_can_I_make_new_terminals_start_in_the_working_directory_of_the_current_terminal.3F

Environment

  • Starship version: starship 0.16.0
  • Shell type: bash
  • Shell version: GNU bash, version 5.0.7(1)-release (x86_64-redhat-linux-gnu)
  • Shell plugin manager: none
  • Terminal emulator: Gnome Terminal
  • Operating system: Fedora 30

Relevant Shell Configuration

eval "$(starship init bash)"

Starship Configuration

none

Possible Solution

https://wiki.gnome.org/Apps/Terminal/FAQ#How_can_I_make_new_terminals_start_in_the_working_directory_of_the_current_terminal.3F

@frenkel frenkel added the 🐛 bug Something isn't working as expected. label Sep 9, 2019
@frenkel
Copy link
Author

frenkel commented Sep 9, 2019

The magic apparently happens in this file:

❯ cat /etc/profile.d/vte.sh 
# Copyright © 2006 Shaun McCance <shaunm@gnome.org>
# Copyright © 2013 Peter De Wachter <pdewacht@gmail.com>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

# Not bash or zsh?
[ -n "$BASH_VERSION" -o -n "$ZSH_VERSION" ] || return 0

# Not an interactive shell?
[[ $- == *i* ]] || return 0

# Not running under vte?
[ "${VTE_VERSION:-0}" -ge 3405 ] || return 0

__vte_urlencode() (
  # This is important to make sure string manipulation is handled
  # byte-by-byte.
  LC_ALL=C
  str="$1"
  while [ -n "$str" ]; do
    safe="${str%%[!a-zA-Z0-9/:_\.\-\!\'\(\)~]*}"
    printf "%s" "$safe"
    str="${str#"$safe"}"
    if [ -n "$str" ]; then
      printf "%%%02X" "'$str"
      str="${str#?}"
    fi
  done
)

# Print a warning so that anyone who's added this manually to his PS1 can adapt.
# The function will be removed in a later version.
__vte_ps1() {
  echo -n "(__vte_ps1 is obsolete)"
}

__vte_osc7 () {
  printf "\033]7;file://%s%s\033\\" "${HOSTNAME:-}" "$(__vte_urlencode "${PWD}")"
}

__vte_prompt_command() {
  local command=$(HISTTIMEFORMAT= history 1 | sed 's/^ *[0-9]\+ *//')
  command="${command//;/ }"
  local pwd='~'
  [ "$PWD" != "$HOME" ] && pwd=${PWD/#$HOME\//\~\/}
  printf '\033]777;notify;Command completed;%s\033\\\033]0;%s@%s:%s\033\\%s' "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)"
}

case "$TERM" in
  xterm*|vte*)
    [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command"
    [ -n "$ZSH_VERSION"  ] && precmd_functions+=(__vte_osc7)
    ;;
esac

true

@frenkel
Copy link
Author

frenkel commented Sep 10, 2019

Fixed it by reading the documentation 🤓

starship_precmd_user_func="__vte_prompt_command"

@chipbuster
Copy link
Contributor

@frenkel Glad to hear you fixed it!

I didn't realize that VTE was hooking PROMPT_COMMAND like this. We actually have a patch coming in that will avoid overriding PROMPT_COMMAND like we currently do, but we'll keep this issue in case it helps someone else in the future.

@chipbuster
Copy link
Contributor

Possibly also fixed by #336

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working as expected.
Projects
None yet
Development

No branches or pull requests

3 participants