After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 579291 - gnome-terminal opens tabs with 'wrong' working directory
gnome-terminal opens tabs with 'wrong' working directory
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
2.26.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 585047 588715 589177 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-17 13:27 UTC by Pedro Villavicencio
Modified: 2010-02-28 11:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Pedro Villavicencio 2009-04-17 13:27:14 UTC
this report has been filed here:

https://bugs.edge.launchpad.net/gnome-terminal/+bug/362880

"When I open a new tab in gnome-terminal (using shift-control-t), it attempts to open the new tab int he same working directory as the old one. If I am reading a manpage, the new tab opens up in /usr/share/man. It should open in the same directory as from where I ran man from (say, $HOME), not whatever directory man changes to internally."

"I've tried the same with terminator (terminal emulator) and it works as expected opening the right working directory instead of /usr/share/man"

Thanks,
Comment 1 Christian Persch 2009-04-21 11:10:25 UTC
It opens the tab in the cwd of the foreground process in the tab it was opened from. I'm not sure this is a 'wrong' at all.
Comment 2 Thomas Spura 2009-05-12 08:50:08 UTC
with GNOME gnome-terminal 2.24.3 it works for me…

after a 'man git' && shift+control+t it opens in the same directory I was before calling 'man git'

man, Version 1.6f


-> Can't reproduce this bug with the older gnome-terminal...

Is this a regression of gnome-terminal or maybe a man problem?
Comment 3 Christian Persch 2009-07-24 22:17:32 UTC
*** Bug 585047 has been marked as a duplicate of this bug. ***
Comment 4 Christian Persch 2009-07-24 22:18:24 UTC
*** Bug 589177 has been marked as a duplicate of this bug. ***
Comment 5 Christian Persch 2009-07-24 22:18:25 UTC
*** Bug 588715 has been marked as a duplicate of this bug. ***
Comment 6 Christian Persch 2009-08-13 13:26:02 UTC
I'm still not convinced it was the wrong thing to do.

However, it has been disabled in git master for now. 
Comment 7 Christian Persch 2009-08-13 13:32:24 UTC
I'm still not convinced it was the wrong thing to do.

However, it has been disabled in git master for now. 
Comment 8 Daniel Leidert 2009-08-18 08:44:19 UTC
Hm. Why would you expect a new tab to open in /usr/share/man, when you have `man' running in the current tab? Even after thinking for a while about this I cannot see any advantage. I like, that new tabs are opened in the working directory [1], the current tab has. But what are IYO the advantages/reasons to use the working directory of the program running in the current tab? People reported to land in /, /usr/share/man and other paths, where they definitely did not want to end. IMHO this is the behaviour I would expect at last. I expect to open a new tab in a defined location (#525450, #475981) or in the same location the current tab has (525450#c17 - your own comment). I personally prefer the latter.

[1] And IMHO many users agree here:
http://bugzilla.gnome.org/show_bug.cgi?id=525450
Comment 9 Daniel Leidert 2009-09-20 14:23:32 UTC
Christian can you please point me to the patch at git.g.o? I cannot find a commit related to this report(?).
Comment 10 Luca Bruno 2010-02-28 09:42:22 UTC
I use all day this kind of feature... why disabling it? Often I have to "duplicate" the tab for using in the same cwd.
Comment 11 Christian Persch 2010-02-28 11:56:09 UTC
*** Bug 611363 has been marked as a duplicate of this bug. ***