Is this just for showing in the title?  In which case, yes, I think switching to requiring the shell to tell makes more sense.

It's used for a) showing the title, and b) opening new tabs in the current directory.

For the latter, we can read the process cwd from /proc on Linux.  We can ignore the issue on other systems I guess?  Or just not try to open in the same dir or something.  Opening in the same dir of a frozen filesystem doesn't produce a usable shell, so that's something else to keep in mind too.

As far as I could determine by searching the web, it simply uses a bash PROMPT_COMMAND which prints "OSC 7 ; <URI> BEL" with the cwd as a properly %-encoded file:/// URI.

Can that be done easily by setting PS1?  If yes, I think we should start accepting that and lobby distros to set it, and stop using chdir() in  later release.

Created attachment 215456 [details] [review]
emulation: Add sequence to set cwd

Add OSC 7 ; URI BEL and OSC 7 ; URI ST sequences to set the cwd as an URI.

I think PROMPT_COMMAND fits better than PS1, since you'll have to use a function to escape the string, and also only do this when running under vte. (I guess we'll need to export some env var for this?)

Function in PS1 is fine.  This is how everyone sets git-bash-completion up:

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u\[\033[00m\]:\[\033[01;34m\]\W\[\033[00m\]\[\033[31m\] $?$(__git_ps1 " (%s)" </dev/null)\[\033[00m\]\$ '

According to http://superuser.com/questions/79972/set-the-title-of-the-terminal-window-to-the-current-directory/321733#321733  there's also OSC 6 used to set the 'represented file'; I think we should add support for that at the same time.

Also, I think xterm has support for something like this already.  Oh yeah, here it is, from my .bashrc:

# If this is an xterm set the title to user@host:dir 
case "$TERM" in 
xterm*|rxvt*) 
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1" 
    ;; 
*) 
    ;; 
esac

Ok, I see, so Apple added seqs for dir and file specifically.  This actually fixes the old "open in samedir" with symlinked directories too.  Really cool.

Looks like xterm simply ignores those sequences, so it should be fine advocating using it unconditionally under TERM=xterm.

Yes, OSC 0 just sets title+icon-title, so a) there's no guarantee to the terminal that this is actually a file/dir (must apply heuristics), and b) the URI escaping takes care to accurately represent the filename (which may not be representable as valid UTF-8). 

And yes, this solves the symlink problem too.

I guess we should ship a .bashrc snipplet that uses this new sequence.

Created attachment 215471 [details] [review]
emulation: Add sequences to set current directory and file

Add sequences
  OSC 6 ; URI BEL
  OSC 6 ; URI ST
  OSC 7 ; URI BEL
  OSC 7 ; URI ST
that set the current file (OSC 7) and current directory (OSC 6) as an URI.

Created attachment 215588 [details] [review]
bash: Add /etc/profile.d/vte.sh script

This script exports __vte_ps1 which when used in PS1 will keep the terminal
updated about the current directory. Use like this in ~/.bashrc:

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

(In reply to comment #12)
> Looks like xterm simply ignores those sequences, so it should be fine
> advocating using it unconditionally under TERM=xterm.

The only problem is that old (pre-this patch) vte doesn't ignore them... that should only matter for us developers however.

Created attachment 215589 [details] [review]
server: Stop using chdir and readlink

They really don't work, and may hang the process (see bug #622180).
Instead, rely on the shell to keep the terminal updated about the
current directory via vte's new current-directory-uri property that
can be updated via the OSC 7 ; URI BEL escape sequence.
vte helpfully installs a script to /etc/profile.d that does via the
shell prompt. Just put this in your ~/.bashrc:

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

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

*** Bug 622180 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> Can that be done easily by setting PS1?  If yes, I think we should start
> accepting that and lobby distros to set it, and stop using chdir() in  later
> release.

IMHO we should just switch to this *right away*, it's simply better :-) Oh, and the symlinks now work! Also, the only thing that breaks if you don't use the PS1 with the escape sequences is that your new-tab/new-window terminals open in $HOME instead of whereever; so that wouldn't be a huge bug.

Fixed on vte-0-34 and vte-next, and g-t master. Relnoting filed as bug 677467.

Sorry for digging up an old bug, but I think it would be useful if one of you would post to a blog or somewhere why this change is useful/needed now that gnome-terminal 3.8 has been released as stable.

How do you recommend distros handle upgrading users to this version? I'm assuming you aren't recommending everyone should manually add an extra line to their ~/.bashrc to avoid a regression...

(My last post was inspired by http://morefedora.blogspot.com/2013/04/gnome-terminal-38.html but I've been frustrated by this for a few months and I still haven't figured out what Ubuntu or Debian will need to change to get this to work out of the box.)

I don't blog. I agree it's useful to know, which is why it's mentioned in NEWS.

I don't think 'everyone' needs to update their bashrc manually; I envisioned that distributions would patch their default bash settings.

/etc/profile.d/vte.sh is sourced automatically (at least that works here on F17), so alternatively we could make it alter the PS1 accordingly, for interactive shells and on condition test "$COLORTERM" = "gnome-terminal" ? That would exclude other vte-based terminal emulators from using this feature however. Also I didn't do this because I got the idea from git's prompt integration feature, which isn't installed by default either.

Unless I'm mistaken, /etc/profile.d/vte.sh is only sourced for *login* shells, so it's not present in gnome-terminal shells.

Discussion on that is continuing in bug 697475.