Description of problem: From the gnome-terminal 3.7.0 changelog: To make new tabs opened within Terminal have the same same working directory as the current tab, it is necessary for the shell running in the terminal to cooperate. For this, vte installs a bash shell script that you must use in your bash PS1 prompt. For example, you can put this at the end of your ~/.bashrc: export PS1=’\[$(__vte_ps1)\]‘$PS1 This is pretty much impossible to discover after an upgrade; and Google is not your friend because you'll find more often than people working with past releases of gnome-terminal request the opposite (open all new tabs on the home directory). Perhaps the aforementioned line should be added at the end of vte.sh? What I did as an alternative is to make the default profile run this command: bash -ic "PS1='\\[\$(__vte_ps1)\]'\$PS1; export PS1; exec $SHELL" but it only works with bash, has to be done manually for all profiles, and is hard to extend to profiles that already use "bash -c". Version-Release number of selected component (if applicable): gnome-terminal-3.7.91-1.fc19.x86_64 vte-0.28.2-8.fc19.x86_64
If you are using gnome-terminal, you want vte3, not vte (the gtk2 version). Also, it looks like vte3 does ship this as an /etc/profile.d/ script...
Oops, yes it is vte3: vte3-0.34.2-4.fc19.x86_64 It does ship vte.sh, but it is not enough. It only provides the functionality, then you have to modify .bashrc too.
Right now I'm putting this in /etc/sysconfig/bash-prompt-xterm: . /etc/profile.d/vte.sh printf "\033]0;%s@%s:%s\007\033]7;file://%s%s\a" "${USER}" \ "${HOSTNAME%%.*}" "${PWD/#$HOME/~}" "${HOSTNAME:-}" \ "$(__vte_urlencode ${PWD})" It is possible that a vte3 update will render this unnecessary, but otherwise the "New tab is not opened in same directory as previous tab" feature is broken in F19 with GNOME 3.8.
Using vte 0.34.5, no changes to ~/.bashrc or /etc/sysconfig/bash-prompt-xterm should be necessary.
Great. Thanks, Christian!
For anyone like me who wants to do his own things with PROMPT_COMMAND and formatting the window title, I found that $(__vte_osc7) is now the piece that prints just the "file://..." update for vte. In fact, I don't really understand why $(__vte_ps1) should print an "obsolete" message. Couldn't you just leave it working for people who want finer control?
Indeed, the main problem is that now vte.sh hijacks PROMPT_COMMAND and the whole PROMPT_COMMAND handling in /etc/bashrc is effectively disabled when vte3 is installed.
Just to be sure - what change do you propose in setup package files? In interactive mode, profile.d scripts are sourced before the bashrc file and PROMPT_COMMAND setting.
I suggest removing the bash test from this statement at the end of vte.sh: case "$TERM" in xterm*|vte*) [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" [ -n "$ZSH_VERSION" ] && chpwd_functions+=(__vte_osc7) ;; esac and applying something like this to /etc/bashrc: --- /etc/bashrc 2013-05-14 13:41:59.397851092 +0200 +++ bbb 2013-05-23 16:03:49.576525068 +0200 @@ -12,9 +12,11 @@ if [ "$PS1" ]; then if [ -z "$PROMPT_COMMAND" ]; then case $TERM in - xterm*) + xterm*|vte*) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm + elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then + PROMPT_COMMAND="__vte_prompt_command else PROMPT_COMMAND=xyz fi This way, bash-prompt-xterm still wins over the vte default.
(In reply to Ondrej Vasik from comment #8) > Just to be sure - what change do you propose in setup package files? In > interactive mode, profile.d scripts are sourced before the bashrc file and > PROMPT_COMMAND setting. For my part, I just want to make sure there's some supported way to tell VTE what it wants without relinquishing my personal PROMPT_COMMAND. That's separate from the goal of making a good distro default, but still important IMO.
setup-2.8.71-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/setup-2.8.71-1.fc19
Package setup-2.8.71-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing setup-2.8.71-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10339/setup-2.8.71-1.fc19 then log in and leave karma (feedback).
I don't think this is the best solution. I'd rather go for something like the zsh solution, ie use an array of functions. Something like this: # have /etc/profile and /etc/bashrc declare an array before sourcing the scripts declare -a __prompt_command_functions # then they source the /etc/profile.d/*.sh scripts # a script can add a function to the array, e.g.: # # my_prompt() { echo "hello"; } # # __prompt_command_functions+=(my_prompt) # define our default /etc/bashrc prompt command __fedora_prompt_command() { printf "\033]0;%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'; } __prompt_command_functions+=(__fedora_prompt_command) # a function that calls all the funcs in the array __prompt_command() { local fun; for fun in ${__prompt_command_functions[@]}; do $fun; done } # now set PROMPT_COMMAND if [ "$PS1" ]; then if [ -z "$PROMPT_COMMAND" ]; then case $TERM in xterm*|vte*) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm else PROMPT_COMMAND=__prompt_command fi # ... esac fi fi Also, I don't like doing a fedora-only thing; ideally the vte.sh script should work on all distros, so I'd love to have some coordination between distros for this.
Overriding envvars by custom profile.d scripts is not nice practice - and playing with arrays for PROMPT_COMMAND seems to be over-engineering to me. Though you may not like Paolo's proposal, I don't like the array proposal.
setup-2.8.71-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Why not just implement a check in /etc/profile.d/vte.sh like in /etc/bashrc, something like: if [ -z "PROMPT_COMMAND" ]; then PROMPT_COMMAND="__vte_prompt_command" else PROMPT_COMMAND="$PROMPT_COMMAND; __vte_prompt_command" fi