Bug 985050

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.

(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.

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.

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.

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"

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.

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)

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.

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.

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.

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.

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.

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.

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)

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.

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.