gnome-terminal >= 3.7 requires sourcing of vte.sh login script

[Tim Lunn]

As of gnome-terminal 3.7.0, it is required to add the following to PS1 to get the usual behaviour where a new terminal opens with the current working directory of the terminal you activated it from.

export PS1='\[$(__vte_ps1)\]'$PS1

gnome-terminal devs suggest to put this in .bashrc, however since this basically causes a regression, it would make sense to deal with it at a distro level and perhaps include it in the system bash scripts or similar.

The actual change was made in libvte so this may potentially affect any application that uses that library.

As a side note: __vte_ps1() is provided by /etc/profile.d/vte.sh, which is installed by libvte, however atleast on my system this script is not getting sourced at login for some reason.

[Tim Lunn (darkxst)]

For > 3.8 it is just required to source the vte.sh script. It is no longer required to mess around with exporting an updated PS1.

As a workaround, add the following line to the end of ~/.bashrc:
. /etc/profile.d/vte.sh

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[xavierzhao (xavierzhao-private)]

Hi, Tim
I was added . /etc/profile.d/vte.sh to end of ~/.bashrc, but not working

[falstaff (falstaff)]

For me, this workaround worked.

[Lta (elthariel)]

Fixes it for me. Thanks

Sources it for .zshrc, .bashrc or both depending on the shell you're using

[Pioneer Skies (alessandro-fazzi)]

Fixed for me too on 14.04

[Martin Pitt (pitti)]

Please let's not do this madness in Ubuntu. Setting the initial dir doesn't require any of this $PS1 hackery, and it's outright impossible to inject it for any existing home dir (i. e. majority of cases). Running the login shell executable in the desired directory is the direct, clean, and non-hackish way.

[Egmont Koblinger (egmont-gmail)]

I (a recent vte/gnome-terminal developer) firmly disagree with the previous comment's proposal in multiple levels, please see https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 - #c44 for my response. Sourcing vte.sh from .bashrc or /etc/bash.bashrc, as per the original ticket, is the right way to go.

[Martin Pitt (pitti)]

Followed up upstream at https://bugzilla.gnome.org/show_bug.cgi?id=697475#c43 ff., and discussed in #ubuntu-desktop. To unblock the update to 3.14 we'll revert https://git.gnome.org/browse/gnome-terminal/commit/?id=cf3cad876 (i. e. short-circuit the env var hack and putting back cwd_of_pid() to read the cwd from there).

[Egmont Koblinger (egmont-gmail)]

Sorry, I missed the fact that you're not a random single user, but Ubuntu's developer finally updating gnome-terminal. I'm grateful you're doing it and supportive of your work!

You *don't* need to modify any user's existing settings!

You need/should modify some global files under /etc, such as profile, bashrc and/or zshrc. You can figure it out. The simplest approach is as simple as three lines in /etc/bash.bashrc sourcing vte.sh (conditionally to the existance of the file, of course), and something similar for zsh. (It's a bit tricky because it's already sourced by profile.d, but since terminals bring up non-login shells you need to source it from bash.bashrc instead, or from both which should be harmless.) Each distro does this whole business of profile/bashrc/etc. differently so vte can't offer an out-of-the-box solution, but it should be very easy to accomodate it to Ubuntu's setup.

I myself as a vte/gnome-terminal developer and Ubuntu user, I strongly discourage you from deviating from mainstream gnome-terminal and reverting to an older approach. It's technically inferior, obsolete, will cause significant maintenance cost, give users a worse experience, and you'll not have support from mainstream developers.

Please accept mainstream gnome-terminal's decision, and tailor it to Ubuntu's needs. Feel free to move vte.sh to a different directory (like /etc/bashrc.d or so), feel free to customize it, feel free to remove setting the window title (I myself hate that and remove this part for myself), feel free to reimplement it from scratch, whatever. But please do keep this architecture!

I cannot / don't want to join an IRC channel, I'd be grateful if all discussions happened here, publicly visibly. I'd be happy to see Ubuntu move forward rather than backward, accomodating new technologies rather than reverting them.

[Egmont Koblinger (egmont-gmail)]

Also, if you really hate to touch configs and love to patch binaries, how about patching bash/zsh to automatically emit OSC 7 without any configs or env vars? :) I know it sounds crazy first, but if you think about it for a while, it's probably not such a brain-damaged idea after all, is it?

[Martin Pitt (pitti)]

OK, then we need to figure out the scope of how many people will likely set $PROMPT_COMMAND in their ~/.bashrc (i. e. which older releases had that in their /etc/skel/, or perhaps it was just added there manually). If that's reasonably small or has never been in /etc/skel/, we can revisit what's wrong with sourcing /etc/profile.d/ or fiddle with that accordingly.

> patching bash/zsh to automatically emit OSC 7

That would be a question for Matthias Klose (our bash maintainer), but what does that mean? Googling for "OSC 7" isn't very useful, I'm afraid :)

Thanks, Martin

[Martin Pitt (pitti)]

Further discussion in the upstream bug showed a better compromise:

 - Let's use vte.sh for the cases where ~/.bashrc doesn't overwrite $PROMPT_COMMAND
 - Add back cwd_from_pid() as a fallback for the other cases, to avoid regressions.

[Egmont Koblinger (egmont-gmail)]

Indeed it could be crucial to know if PROMPT_COMMAND was ever present in /etc/skel. I think it's fair game if users who have once touched their configs will need to touch that again.

And it's not that they'll live with something fundamentally broken until then - it's one convenience feature that won't work, and they'll be able to quickly look up the answer on the net.

Okay I didn't *really* mean to patch bash/zsh, but it's something to think about for a while, for fun. OSC stands for operating system command, this is the escape sequence \e]. OSC 0 is used to change the terminal's title, OSC 7 is used to change its notion about the current working directory, as you can see in vte.sh.

[Martin Pitt (pitti)]

Egmont Koblinger [2014-10-07 10:16 -0000]:
> Indeed it could be crucial to know if PROMPT_COMMAND was ever present in
> /etc/skel. I think it's fair game if users who have once touched their
> configs will need to touch that again.

Yes, I agree.

> OSC stands for operating system command, this is the escape sequence
> \e]. OSC 0 is used to change the terminal's title, OSC 7 is used to
> change its notion about the current working directory, as you can
> see in vte.sh.

Ah I see, thanks!

[Egmont Koblinger (egmont-gmail)]

One more thing to consider with the "fallback" approach:

If you do this, users who've manually set PROMPT_COMMAND will remain with the old method of figuring out the cwd, including all its bugs and limitations (not remembering symlink components, not working after sudo, etc.) They would probably live on with these compromises, unaware that there is a better solution.

If you don't do the fallback, those users will be pushed to switch to the new, better solution with all its advantages.

Your call. I would personally probably do the fallback if /etc/skel ever shipped a PROMPT_COMMAND for the sake of those users, but not ship the fallback otherwise.

[Egmont Koblinger (egmont-gmail)]

Looking at http://old-releases.ubuntu.com/ubuntu/pool/main/b/bash/, it seems that up to bash_3.2-0 (which was shipped by Hardy 08.04 LTS) bash's /etc/skel/.bashrc defined
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'

Beginning with bash_3.2-4 (Intrepid 08.10) PROMPT_COMMAND is no longer present in files shipped by bash under /etc/skel.

[Martin Pitt (pitti)]

Cheers, thanks for the research! That explains where my ~/.bashrc got that PROMPT_COMMAND from.

[Martin Pitt (pitti)]

Patch sent upstream (rejected though), and applied to our gnome-terminal packaging bzr.

[Egmont Koblinger (egmont-gmail)]

Thanks Martin!

I guess it's way too late for Utopic, but will make it into VV, correct?

[Martin Pitt (pitti)]

Egmont Koblinger [2014-10-15 9:18 -0000]:
> I guess it's way too late for Utopic, but will make it into VV, correct?

Right. Utopic releases next week, and shipping and outdated
g-terminal is far from being release-critical. So it will land as soon
as V opens.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-terminal - 3.12.2-0ubuntu1

---------------
gnome-terminal (3.12.2-0ubuntu1) vivid; urgency=low

  [ Iain Lane ]
  * NOTE: This version changes behaviour around the "Switch to tab" keyboard
    shortcuts. They are now active all the time, whereas previously they were
    only active when you had a corresponding number of tabs open. If you need
    to send these keys to your terminal, clear the shortcuts in the
    preferences dialog.
  * Drop 03_add_keywords.desktop: Not useful any more.
  * Drop 20_add_alt_screen_toggle_ui.patch: Too much effort to maintain, not
    deemed important enough to keep.
  * Resynchronise with Debian, remaining changes:
    - debian/patches/50_add_unity_quicklist.patch: Add Unity quicklist menu
      item.
    - debian/patches/60_add_lp_handler.patch: Add a handler for launchpad bug
      URLs.
  * Disable shell provider, we don't want to build-dep on gnome-shell.
  * Bump build-dependencies according to configure.ac:
    - intltool 0.50.0
    - vte 0.36.0
    - glib 2.39.2
  * Make debian/patches/10_kfreebsd-f_dupfd_cloexec.patch apply again.
  * Add build-dependency on libnautilus-extension-dev
  * Add new patch debian/patches/nautilus-x11.patch
    - build fails because of -Wl,-z,defs missing -lX11 in nautilus extension
  * Include autoreconf.mk cdbs snippet and build-depend on dh-autoreconf
  * Install new files in gnome-terminal
    - nautilus extension
  * debian/patches/0001-Restore-transparency.patch: Patch from Debarishi Ray
    to re-add support for transparent terminals. Updated to support loading a
    transparency value from the theme, if it provides one and to migrate the
    settings from GConf.

  [ Jeremy Bicha ]
  * debian/rules:
    - Build with --enable-distro-packaging to not override Ubuntu
      environment variables
  * debian/patches/52_support_apturl.patch:
    - Support apt: URIs (LP: #217611)

  [ Martin Pitt ]
  * Add 61_cwd_fallback.patch: Provide fallback for reading current directory
    if OSC 7 fails. (LP: #1132700)
 -- Iain Lane <email address hidden> Wed, 05 Nov 2014 15:55:30 +0000

[Egmont Koblinger (egmont-gmail)]

Great, thanks!

While we're at it, could you please make sure to upgrade to vte-0.36.3 and gnome-terminal-3.12.3?

Both contain important bugfixes, especially gnome-terminal-3.12.3 fixes a nasty crash that happens relatively often.

We're talking about minor version numbers here, it should be as easy as bumping the version number.

[Martin Pitt (pitti)]

Oh, I expect us to upgrade to 3.14 ASAP. We just had 3.12 prepared for quite some time, and as you say for 3.14 we need to upgrade vte first, so we wanted to land this in two smaller steps.

[Egmont Koblinger (egmont-gmail)]

Fair enough, thanks :)

[Iain Lane (laney)]

On Thu, Nov 06, 2014 at 09:26:54AM -0000, Egmont Koblinger wrote:
> Fair enough, thanks :)

This was trivial to do as you suggested so I just did it. Might as well
save people from crashers in the meantime. :)

I do want to move to 3.14, but I'm not sure if the team which decides
our 'supported' components will let us have two versions of vte
supported at the same time, so we might have to work on moving

laney@iota> reverse-depends -c main src:vte3
Reverse-Depends
===============
* language-selector-gnome (for gir1.2-vte-2.90)
* python-aptdaemon.gtk3widgets (for gir1.2-vte-2.90)
* python3-aptdaemon.gtk3widgets (for gir1.2-vte-2.90)
* remmina (for libvte-2.90-9)
* ubiquity-frontend-gtk (for gir1.2-vte-2.90)
* ubuntu-release-upgrader-gtk (for gir1.2-vte-2.90)
* update-manager (for gir1.2-vte-2.90)

to 2.91 in parallel with this. (This is work we should do anyway)

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Egmont Koblinger (egmont-gmail)]

I'm not sure what 'supported' means in this context, but I guess it's something like the core/default packages of Ubuntu (e.g. config tools, default desktop including gnome-terminal etc.) as opposed to the additional software (e.g. other vte-based terminals). Am I right?

I understand that the former category is more important, and that supporting two parallel versions is not ideal. On the other hand, blocking update of these components until all of them has a vte-0.38-based version released doesn't sound even worse to me.

The weren't too many API changes, so for Ubuntu-maintained software the transition could probably be made really quickly. The bottleneck is of course apps that are not Ubuntu-specific.

What really sucks is those apps that still use Gtk+2/vte-0.28, this ancient version of Vte contains dozens of severe bugs that were fixed in the mean time. (vte-0.36.3 is the first one I personally feel good about :)) However, at this point there's nothing we could do to urge them porting to Gtk+3.

[Egmont Koblinger (egmont-gmail)]

A BIG FAT WARNING ABOUT PARALLEL VTE 0.36/0.38 INSTALLS VS BRAIN-DAMAGED PYTHON GIR:

https://bugzilla.redhat.com/show_bug.cgi?id=1114379 (especially comment 9)

Summary: Just by installing vte-0.38 (next to the already installed vte-0.36), python apps that happily used 0.36 before will now try to include 0.38 instead and hence break big time.

All the python code using vte requires to be ported to vte-0.38 (library version 2.91), or have an explicit version requirement to 0.36 (actually: library version 2.90).

[Egmont Koblinger (egmont-gmail)]

Typo: ... On the other hand, blocking update of these components until all of them has a vte-0.38-based version released *sounds* even worse to me.

[Shaav (shaav)]

In case someone like me comes across this discussion but the workaround for the issue doesn't work:

Turns out that in the Profile Preferences' Command tab, if the "Run a custom command instead of my shell" is checked, the same problem occurs, but is likely unrelated to this bug. (Right click in the terminal->Profiles->Profile Preferences->Command)