Bug 985050 - [regression?] current directory of new instance no longer set to parent's.
[regression?] current directory of new instance no longer set to parent's.
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-terminal (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-16 12:29 EDT by Hin-Tak Leung
Modified: 2015-02-17 11:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 11:11:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hin-Tak Leung 2013-07-16 12:29:28 EDT
Description of problem:
In gnome 3.6/F18, new tab/windows from an existing gnome-terminal, opens a new instance with its current directory set to the parent. This is no longer the case. It isn't set to $HOME either, but some fix one in the distant ancestor, I think.

Version-Release number of selected component (if applicable):
gnome-terminal-3.8.4-1.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1.launch on gnome-terminal, cd to say, /tmp
2. select new tab/windows from its menu
3. 

Actual results:
The new instance has current directory still at $HOME.

Expected results:
it should inherit from the parent.

Additional info:
This is breaking years of convention, as well as being very inconvenient - if the user's intention is to start over at $HOME, it is far easier to do a "cd" to go back to some fix place. Whereas it is often not easy to cd "whatever whatever" to go to where the parent was, so it should really by default go to the parent's current directory.
Comment 1 Christian Persch (GNOME) 2013-07-17 05:29:02 EDT
Which shell do you run? This works with bash/zsh, see https://wiki.gnome.org/Terminal/FAQ#How_can_I_make_new_terminals_start_in_the_working_directory_of_the_current_terminal.3F for more information.

In any case, not a gnome-terminal bug.
Comment 2 Hin-Tak Leung 2013-07-17 06:04:43 EDT
(In reply to Christian Persch (GNOME) from comment #1)
> Which shell do you run? This works with bash/zsh, see
> https://wiki.gnome.org/Terminal/
> FAQ#How_can_I_make_new_terminals_start_in_the_working_directory_of_the_curren
> t_terminal.3F for more information.
> 
> In any case, not a gnome-terminal bug.

bash. I have a /etc/profile.d/vte.sh from vte3-0.34.6-1.fc19.x86_64 . That tests for $BASH_VERSION , but interestingly, that environment variable isn't set.
bash version is bash-4.2.45-1.fc19.x86_64 .

$ export | grep -i bash
declare -x SHELL="/bin/bash"

no such environment variable as $BASH_VERSION . 

Please feel free to re-assign, but the FAQ seems to be wrong in this instance, for fedora 19, at least.
Comment 3 Christian Persch (GNOME) 2013-07-17 09:12:22 EDT
Your check is simply broken: BASH_VERSION is always set in bash, but it's no exported. Just echo $BASH_VERSION and you'll see.
Comment 4 Christian Persch (GNOME) 2013-07-17 09:27:28 EDT
Maybe your ~/.bashrc (or ~/.bash_profile is overwriting the PROMPT_COMMAND variable? You mustn't do that for this feature to work (or if you do, you need to append __vte_osc7 to it).

In any case, this works for everyone else, so I don't think this is a bug in vte or gnome-terminal.
Comment 5 Hin-Tak Leung 2013-07-17 09:35:43 EDT
Argh, autojump also plays with $PROMPT_COMMAND : 

# grep PROMPT_COMMAND  /etc/profile.d/*
/etc/profile.d/autojump.bash:case $PROMPT_COMMAND in
/etc/profile.d/autojump.bash:    *)   export PROMPT_COMMAND="autojump_add_to_database; ${PROMPT_COMMAND:-:}";;
/etc/profile.d/vte.sh:    [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command"
Comment 6 Christian Persch (GNOME) 2013-07-17 11:42:23 EDT
In bug 924275 comment 13 I proposed a way to better organise multiple sources adding to PROMPT_COMMAND, but unfortunately the suggestion wasn't received favourably by the maintainer.
Comment 7 Hin-Tak Leung 2013-07-18 06:26:48 EDT
I am not sure why gnome-terminal should mess with and its working correctly should depend on PROMPT_COMMAND . PROMPT_COMMAND is a rather flaky business, and many people have customizations that they may forget about, or want to keep.

FWIW, I do/did. It came about when autojump broke the default bash prompt. In that case, I understand why autojump needs it, and decided to merge its and the default's. autojump records a user's most often-used directory and make it possible to do "j <partialpath><tab>", with auto-completion, jump to a deep/long but often used path. It sort of makes sense to overload PROMPT_COMMAND, or trap the result of "cd" command somehow, to do that.

But launching a new child terminal doesn't really involve a deliberate "cd". I was expecting it to work like most unix applications, xterm in particular, where environment variables are inherited, including $PWD. (I have no knowledge how child xterm inherits parent xterm's CWD, but I imagine it does not do so via PROMPT_COMMAND)
Comment 8 Hin-Tak Leung 2013-07-18 06:36:50 EDT
I am saying that due to past problems, I have incorporated (part of)
/etc/profile.d/autojump.bash into my ~/.bashrc . But it sure this is a general issue that multiple software wants to mess with PROMPT_COMMAND, and overriding each other's changes, as well as users having personal or site-wide customizations for other reasons.

I just think gnome-terminal shouldn't rely on such a commonly messed-with and frequently customized and personalized part of a system staying "as shipped" to work.
Comment 9 Christian Persch (GNOME) 2013-07-18 11:54:11 EDT
Since there's no g-t bug here, I suggest someone with the necessary bugzilla privleges close this report as NOTABUG.

I'll clarify the FAQ wrt. to user modification of PROMPT_COMMAND.
Comment 10 Hin-Tak Leung 2013-07-18 14:34:14 EDT
Depending on a state that other software often messes with, and also one that is frequently customized one a personal or site-wide basis, seems to be a "stupidity from the start", if one doesn't want to call it a "bug".

Also, from looking at /etc/profile.d/autojump.bash and /etc/profile.d/vte.sh , 
autojump.bash doesn't break vte.sh, but vte.sh does break autojump.bash (autojump.bash concatenates previously set PROMPT_COMMAND, while vte.sh discards it). So depending on the load order, vte.sh breaks another application and interfere with another application's operation. It is entirely possible another /etc/profile.d/* would break vte.sh in turn, again, depend on which one get run first.

The FAQ really just amount to: "We decided to add a bug in 3.7, here is how you learn to cope with it..." - while the FAQ helps, this new "feature" isn't attractive.
Comment 11 Christian Persch (GNOME) 2013-07-18 14:41:00 EDT
Nothing requires you to use this feature if you don't find it 'attractive'; you simply won't have new tabs opened in the same cwd as the previous tab. Since that was the original complaint in comment 0, I don't think arguing further is going to change anything, so I'll stop.
Comment 12 Hin-Tak Leung 2013-07-18 15:09:37 EDT
You can say opening tabs is a relatively new feature, but opening new windows (new instances) of xterm has always follows cmd. This new "feature" or "stupidity" breaks 20+ years of tradition.

And, 3.6 gnome-terminal did work (for whatever reason). So it is a "bug addition". One useful addition to the FAQ would be to explain why adding this feature/bug is necessary.
Comment 13 Fedora End Of Life 2015-01-09 13:57:13 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Trevor Cordes 2015-01-10 05:31:36 EST
I still see this issue with F21 (tcsh, custom prompts).  I think this is the same bug as Bug 981266?

I skimmed the info in this bug and from the discussion I'm unsure as to whether this should even work for me with tcsh, so I apologize if me reporting it as "still a bug" is useless, as I never tried SH-CTL-N before today.  I tried chsh to bash and testing and I could could not get the cwd to inherit to the child either, but I was adhoc testing and never use bash and could have wonky config seeing as how I've deleted all my ~/.bash* related stuff.

(When I did set PROMPT_COMMAND="__vte_prompt_command" in my ~/.bashrc and SH-CTL-N the new window said: bash: __vte_prompt_command: command not found)
Comment 15 David Woodhouse 2015-01-11 08:05:44 EST
I'm not sure that my bug 981266 is a duplicate. This bug seems to be about brokenness in setting $PROMPT_COMMAND to include __vte_osc7(), but mine *does*, and even invoking __vte_osc7 manually doesn't make any difference here.
Comment 16 Fedora End Of Life 2015-02-17 11:11:35 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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