Bug 919643

Summary: [Regression] Can no longer open new tab/window in same directory as original tab
Product: [Fedora] Fedora Reporter: Michel Lind <michel>
Component: gnome-terminalAssignee: Matthias Clasen <mclasen>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: chpe, giallu, kparal, mclasen, nalin, tim
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 2160311 (view as bug list) Environment:
Last Closed: 2013-07-08 15:48:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2160311    

Description Michel Lind 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):
gnome-terminal-3.7.91-1.fc19.x86_64

How reproducible:
Always

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 Lind 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 Lind 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:

https://bugzilla.gnome.org/show_bug.cgi?id=622180

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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

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 Lind 2013-07-08 15:48:51 UTC
Confirmed that it works with bash and zsh, thanks