Bug 919643 - [Regression] Can no longer open new tab/window in same directory as original tab
Summary: [Regression] Can no longer open new tab/window in same directory as original tab
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-03-09 06:04 UTC by Michel Alexandre Salim
Modified: 2013-07-09 13:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-08 15:48:51 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 697475 0 Normal RESOLVED New tab is not opened in same directory as previous tab 2020-05-04 12:21:18 UTC

Description Michel Alexandre Salim 2013-03-09 06:04:29 UTC
Description of problem:
Up to GNOME 3.6, it is possible to start a new terminal tab/window starting in the same directory as the currently-focused shell.

This is no longer possible - the context menu is no longer present, and launching a new tab using Ctrl-Shift-T or using the menu drops one in one's home directory

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start gnome-terminal
2. Navigate to another directory
3. Start a new tab
Actual results:
New tab's current directory is ~

Expected results:
There should be a way, as before, to have the new tab start in the cwd of the active shell

Additional info:

Comment 1 Michel Alexandre Salim 2013-03-09 06:05:28 UTC
This should perhaps be reported upstream as well, but I've not had the chance to verify if the bug is also present there

Comment 2 Christian Persch 2013-03-15 12:08:07 UTC
This is not an upstream bug. Citing the gnome-terminal release notes:

   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

Comment 3 Michel Alexandre Salim 2013-03-16 05:38:59 UTC
Aha, yes, documented for 3.7.0. Any reason for the change from the old behavior?

We should probably coordinate this with Bash and ZSH shell maintainers so that the user experience does not change unexpectedly.

Comment 4 Gianluca Sforna 2013-03-17 17:38:40 UTC
It seems the main reason is that there is a (corner?) case where things can go really wrong:


I am not able to judge whether this was the best fix to apply, but surely we need to document it in release notes and other F19 material.

Comment 5 Nalin Dahyabhai 2013-03-18 17:42:05 UTC
Please don't forget csh (or tcsh, as it goes).

Comment 6 Fedora End Of Life 2013-04-03 16:12:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 7 Christian Persch 2013-07-08 08:50:46 UTC
Since vte 0.34.5 (F19 final has 0.34.6) this is all automatic, so this bug can be closed now.

It should work on bash and zsh.

Re comment 5, there is no [t]csh support, since nobody has requested that upstream. (Since upstream doesn't use [t]csh, a patch would be required.)

Comment 8 Michel Alexandre Salim 2013-07-08 15:48:51 UTC
Confirmed that it works with bash and zsh, thanks

Note You need to log in before you can comment on or make changes to this bug.