GNOME Bugzilla – Bug 697475
New tab is not opened in same directory as previous tab
Last modified: 2018-09-11 12:13:52 UTC
At least with gnome-terminal-2.32, I remember I was able to simply press Ctrl+shift+T to open a new tab, and that tab was opened in the same directory used by previous tab. I have tried to find some configuration of this behavior in Preferences but haven't found anything. New tab is always opened in ${HOME}, and that can be annoying when you were in some deep subdirectory :S Thanks
*** This bug has been marked as a duplicate of bug 697025 ***
FWIW, I solved it on Debian by adding this snippet to ~/.bashrc: case "$TERM" in xterm) . /etc/profile.d/vte.sh export PS1='\[$(__vte_ps1)\]'$PS1 ;; esac
That looks wrong. The point of vte.sh being in /etc/profile.d is that it will be sourced automatically; and that works here on fedora 17. Also, if you do want to make this conditional, you should probably test for "$COLORTERM" = "gnome-terminal", not $TERM.
> The point of vte.sh being in /etc/profile.d is that it will be sourced automatically; and that works here on fedora 17. For some reason it doesn't work here on Debian: if I uncomment that line, I get bash: __vte_ps1: command not found My /etc/profile *does* contain lines that source /etc/profile.d/*.sh. > Also, if you do want to make this conditional, you should probably test for "$COLORTERM" = "gnome-terminal", not $TERM. You are right, but I only use gnome-terminal or TTYs, so this doesn't really matter. But other VTE-based terminals need that line too, right?
(In reply to comment #4) > > The point of vte.sh being in /etc/profile.d is that it will be sourced > automatically; and that works here on fedora 17. > > For some reason it doesn't work here on Debian: if I uncomment that line, I get > > bash: __vte_ps1: command not found > > My /etc/profile *does* contain lines that source /etc/profile.d/*.sh. On fedora, /etc/profile.d/*.sh are sourced for both login shells and non-login shells; maybe debian is different? Or it's a problem with debian using dash instead of bash? > > Also, if you do want to make this conditional, you should probably test for > "$COLORTERM" = "gnome-terminal", not $TERM. > > You are right, but I only use gnome-terminal or TTYs, so this doesn't really > matter. But other VTE-based terminals need that line too, right? Yes, although right now only g-t uses this vte feature.
On fedora, /etc/profile.d/*.sh are sourced for both login shells and non-login shells; maybe debian is different? Or it's a problem with debian using dash instead of bash? Here's how my /etc/profile works: if [ -d /etc/profile.d ]; then for i in /etc/profile.d/*.sh; do if [ -r $i ]; then . $i fi done unset i fi So, if /etc/profile is sourced, then /etc/profile.d/vte.sh is also sourced. Bash doesn't read /etc/profile on startup, it reads /etc/bash.bashrc instead.
On Fedora, /etc/bashrc sources the /etc/profile.d scripts too, and the default bashrc from /etc/skel sources /etc/bashrc. Using COLORTERM might not be the best way either, since COLORTERM really is an anachronism that should just go away. Maybe should define some sort of VTE variable, maybe VTE=(encoded vte version) that can then be tested with test $VTE -gt ...
(In reply to comment #3) > That looks wrong. > > The point of vte.sh being in /etc/profile.d is that it will be sourced > automatically; and that works here on fedora 17. That is neither the case on Gentoo for non-login shells :/
*** Bug 697563 has been marked as a duplicate of this bug. ***
*** Bug 697025 has been marked as a duplicate of this bug. ***
*** Bug 698105 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > On Fedora, /etc/bashrc sources the /etc/profile.d scripts too, and the default > bashrc from /etc/skel sources /etc/bashrc. Maybe we could change it downstream, but I would need some kind of documentation with the rationale of changing bashrc to source profile.d as looks like this is fedora specific :/ Also: https://bugzilla.gnome.org/show_bug.cgi?id=697025#c1 > Please see the NEWS file for gnome-terminal 3.7.0. This is more of an action > item for your distribution however, but in the meanwhile you can proceed as > recommended there. What should be done downstream? Tell people to read that suggestion from NEWS file or are you applying some change in your gnome-terminal package in Fedora (I couldn't see anything special there :/) Thanks for the info
(In reply to comment #12) > (In reply to comment #7) > > On Fedora, /etc/bashrc sources the /etc/profile.d scripts too, and the default > > bashrc from /etc/skel sources /etc/bashrc. > > Maybe we could change it downstream, but I would need some kind of > documentation with the rationale of changing bashrc to source profile.d as > looks like this is fedora specific :/ Fedora is the Gnome reference distro, so you should simply follow their example here. > Also: > https://bugzilla.gnome.org/show_bug.cgi?id=697025#c1 > > Please see the NEWS file for gnome-terminal 3.7.0. This is more of an action > > item for your distribution however, but in the meanwhile you can proceed as > > recommended there. > > What should be done downstream? Tell people to read that suggestion from NEWS > file or are you applying some change in your gnome-terminal package in Fedora > (I couldn't see anything special there :/) Distros should modify their default bash configuration. How exactly to do that (so that it doesn't interfere with other terminal emulators) isn't totally clear; maybe sth like comment 7 should be implemented.
*** Bug 698792 has been marked as a duplicate of this bug. ***
I'm going to implement the VTE=(version) env variable for vte 0.34.5, but it's not yet clear if it'll be possible to modify vte.sh to alter PS1 itself without help from the distro.
*** Bug 699074 has been marked as a duplicate of this bug. ***
*** Bug 699094 has been marked as a duplicate of this bug. ***
*** Bug 699208 has been marked as a duplicate of this bug. ***
I've added a VTE env variable to vte that's set to the version (ie. VTE=3405 for vte 0.34.5), and changed __vte_ps1 to only print anything for interactive shells under vte. That should take care of not printing anything undesirable under other terminal emulators or the linux console. I don't think automatically modifying PS1 from vte.sh is feasible. At least here on F17, the initialisation order is as follows: - for login shells: /etc/profile sources /etc/profile.d/*.sh ~/.bash_profile sources ~/.bashrc sources /etc/bashrc sets PS1 and PROMPT_COMMAND - for non-login shells: ~/.bashrc sources /etc/bashrc sets PS1 and PROMPT_COMMAND sources /etc/profile.d/*.sh /etc/bashrc contains this line: [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$ " So in the login shell case, when vte.sh is sourced the PS1 is still the initial default value, and /etc/bashrc changes to its 'real default' only if it's still at that initial default value. If we change it in vte.sh, that won't work. (And hardcoding the /etc/bashrc value plus __vte_ps1 won't work because other distros may have different defaults.) So I think the place to put this is in /etc/bashrc (for F17 at least). We can now do this conditionally under [ -n "$PS1" -a "${VTE:-0}" -ge 3405 ]. Whether to modify PS1 (with \[ ... \]) or PROMPT_COMMAND is up to the distro (although I'm leaning toward thinking that PROMPT_COMMAND would be the right place, not PS1).
It looks like it would work to always set PROMPT_COMMAND from vte.sh though, e.g.: __vte_prompt_command() { printf "\033]0;%s@%s:%s\007\033]7;file://%s%s\a" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}" "${HOSTNAME:-}" "$(__vte_urlencode ${PWD})" } [ -n "$PS1" -a "${VTE:-0}" -ge 3405 ] && PROMPT_COMMAND="__vte_prompt_command" then the /etc/bashrc parts won't change it again. Tested this, and it works. Does anyone see any problem with this approach?
As for debian, it appears that /etc/profile.d/*.sh scripts are only sourced for login shells (done in the default /etc/profile, which is copied from /usr/share/base-files/profile on install), but not for non-login shells. That seems to be a problem for the debian maintainers to address, nothing we can do about it.
Do you have any kind of reference or documentation to ask our Gentoo bash maintainers to source /etc/profile.d/ from /etc/bash/bashrc? On Gentoo the behavior is like Debian and I am unsure if asking to change the behavior "because Fedora does" will convince them :( Also, are you sure Fedora is behavior is so "standard", I mean, how is the behavior in other distros like OpenSuSE, for example
If the distro doesn't source /etc/profile.d/*.sh scripts for both login and non-login shells, then vte.sh can't do *anything* to make it work on that distro out-of-the box; so the distro needs to do *something* anyway. *What* exactly that is I don't know; I'm open for suggestions from the actual distro's bash maintainers. So I'm mostly concerned about making it work automatically in distros that do source it both ways (like Fedora, the Gnome reference distro) and without disturbing other terminal emulators that don't understand the vte sequences. The less said about opensuse's /etc/{profile,bash.bashrc} the better… (and it only sources *all* /etc/profile.d/*.sh scripts for login shells).
I have pushed something that works here on F17 to vte-0-34.
Well, I opened: https://bugs.gentoo.org/show_bug.cgi?id=468094 downstream suggesting the change, lets see .... :|
/etc/profile.d/*.sh are for login shells. It doesn't make sense to run them on every shell, when their actions persist on the children. The typical case is to set environment variables. vte.sh is the outlier here by doing things it isn't designed for. It makes more sense to install vte.sh inside /etc/bash_completion.d/ It's not a completion but, just like them, it's intended for interactive shells.
+1 for moving it to /etc/bash_completion.d, that will work on Debian/Ubuntu.
Gentoo bash maintainers also refuse to call profile.d from non-login shells, but would be willing to implement a calling of /etc/bashrc.d/*.sh https://bugs.gentoo.org/show_bug.cgi?id=468094#c1
Moving to bash_completion looks complete wrong. If it works, that's entirely by accident since that's not what bash_completion was designed for. There's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008 about /etc/bashrc.d for debian, but I don't see anything to suggest that the debian maintainers are taking up that suggestion? Nor does it seem to be in ubuntu. Opensuse appears to have actually have had /etc/bashrc.d (it's in aaa_base in 12.2 at least) but have removed it (it's not in aaa_base in factory/13.1; no mention of the issue in changelog, of course) ? And fedora has sourced /etc/profile.d/*.sh scripts from /etc/bashrc since before fedora existed (see https://bugzilla.redhat.com/show_bug.cgi?id=59446 ; it's also the only bug that even mentioned /etc/bashrc.d I could find).
Does anybody know about debian/opensuse/ubuntu maintainers mail to CC them to this bug report and reach a common solution?
I've asked Matthias (the Debian/Ubuntu maintainer) to look at that, he'll probably do that tomorrow. Having a /etc/bashrc.d sounds like a good idea for me.
As a side note - there are other shells then bash like zsh. As bashrc.d implies bash-specific configuration it would be a bit strange for zsh to source /etc/bashrc.d.
The vte.sh script now also works on zsh. On fedora, the default /etc/zprofile sources /etc/profile which again loads the /etc/profile.d/*.sh scripts. And for non-login zsh shells, the default /etc/zshrc file again sources them. So I agree with comment 33 that I don't think a /etc/bashrc.d/ would work. A single location is better than having to install the script to two locations that are sourced according to whether it's a login or non-login shell; and since /etc/profile.d/ exists and fulfills that role for login shells, I don't think it's too much to ask to make it have the same purpose for non-login shells. (In reply to comment #32) > I've asked Matthias (the Debian/Ubuntu maintainer) to look at that, he'll > probably do that tomorrow. What was their reply?
FWIW; I had to remove __vte_ps1 from PS1, as it made bash/gnome-terminal quite confused about the real width (it is probably taking the path written to the terminal as if it was text counting to the window width), just pressing up a few times with long lines (you may also need to be deep in the fs) and you end up, with options appearing at the right of the terminal, with text below from previous lines, and wrapping wrongly. What was wrong with the guessing from child cwd? It may not always have been accurate, but it was much less intrusive.
(In reply to comment #35) > FWIW; I had to remove __vte_ps1 from PS1, as it made bash/gnome-terminal quite > confused about the real width That looks like you forgot the \[...\] around it. In any case, the version of vte.sh in vte-0-34 and that will be in 0.34.5 for gnome 3.8.2 doesn't require PS1 anymore but uses PROMPT_COMMAND.
(In reply to comment #34) > The vte.sh script now also works on zsh. > > On fedora, the default /etc/zprofile sources /etc/profile which again loads the > /etc/profile.d/*.sh scripts. And for non-login zsh shells, the default > /etc/zshrc file again sources them. That doesn't look strange to me because looks like in Fedora there are no problems with running profile.d/*.sh scripts for login and non-login shells (zsh on fedora is behaving like bash on fedora), but it will probably fail in the same way in other distributions that don't want to run profile.d scripts in non-login shells > > So I agree with comment 33 that I don't think a /etc/bashrc.d/ would work. A > single location is better than having to install the script to two locations > that are sourced according to whether it's a login or non-login shell; and > since /etc/profile.d/ exists and fulfills that role for login shells, I don't > think it's too much to ask to make it have the same purpose for non-login > shells. > Why not have a /etc/non-login-shells.d/ (well, we would need to choose a better name probably) to let different scripts being run depending on the type of the shell?
(In reply to comment #34) > > I've asked Matthias (the Debian/Ubuntu maintainer) to look at that, he'll > > probably do that tomorrow. > > What was their reply? <mitya57> doko: any comment on my message? resolving that is listed in the gnome-3.8 blueprint ... <doko> mitya57, didn't look at it yet
*** Bug 692169 has been marked as a duplicate of this bug. ***
Testing ${VTE} is not enough. You need to test $COLORTERM too, otherwise the current directory within an ssh connection will be used when doing Ctrl+N.
I don't see why? ssh doesn't forward the VTE_VERSION variable, so if you ssh into a box that where the shell sources the vte.sh script, it will do nothing.
Re the last two comments: please see bug 709055.
Would you be totally resistant to changing the behaviour back to what we had in 3.6? Nearly every existing system/home dir will already define PS1 in their $HOME/.bashrc (from /etc/skel/). And for something as simple as changing the initial directory it's a waay too big hammer; after all, you can simply exec $login_shell in the directory you want.
(In reply to comment #43) > Would you be totally resistant to changing the behaviour back I personally, would. > to what we had in > 3.6? Nearly every existing system/home dir will already define PS1 in their > $HOME/.bashrc (from /etc/skel/). This story has nothing to do with PS1. We recommend to set PROMPT_COMMAND, as vte.sh does. > And for something as simple as changing the > initial directory it's a waay too big hammer How was digging into /proc in an OS-dependant way to retrieve the directory with certain limitations (e.g. not being able to track after a user change, from a file manager, or remember symlinks) any smaller hammer? And even if it were, who cares about the size of the hammer, if this is the hammer that solves the problem in the best possible known way? Konsole still digs into /proc in a different way than gnome-terminal used to do, which used to (and still does) result in different behavior in a totally user-uncontrollable way. Konsole's author has already agreed that OSC7 is a nicer solution and considers migrating. Xterm's author told me he'll consider this feature. Mac Terminal and iTerm2 (I believe both, maybe just one of them) also uses this feature. ; after all, you can simply exec > $login_shell in the directory you want. Er... what are you talking about? How is it going to open a new terminal window/tab? Or of you open it manually, how is it going to refer to the working directory of the previous tab? Just put ". /etc/profile.d/vte.sh" in your .bashrc and you're done. Deal with it. Please don't ask anyone to alter the design and put significant amount of work in it just because you're lazy to place 1 line of code somewhere. Here are my arguments for the new behavior: no more dirty OS-specific digging in proc; the potential of being consistent across terminal emulators; ability to follow symlinks; ability for file managers (e.g. mc has a pending patch) to set their working directory, while shell scripts or make-like commands internally cd'ing won't tamper with it. As far as I can see, your argument is that it saves a one-time 10-second operation of placing something in .bashrc (which should be done by your distribution, not by you – complain at your distro if they haven't done it yet).
(In reply to comment #44) > This story has nothing to do with PS1. We recommend to set PROMPT_COMMAND, as > vte.sh does. That's marginally better indeed, but still requires changing existing user config files. (Just a tad fewer than for PS1). > How was digging into /proc in an OS-dependant way to retrieve the directory > with certain limitations (e.g. not being able to track after a user change, > from a file manager, or remember symlinks) any smaller hammer? It seems quite straightforward to me. https://git.gnome.org/browse/gnome-terminal/commit/?id=cf3cad87 doesn't have much information beyond "just doesn't work" (why?) and referring to a bug; however, that bug also doesn't explain how a readlink(/proc/pid/cwd) causes any kind of freeze. So yes, I definitively regard reading a file from /proc (it is the *purpose* of /proc/ to get runtime information) a much smaller hammer than asking millions of users to change their personal config files. > And even if it were, who cares about the size of the hammer, if this is the hammer that solves the problem in the best possible known way? As I said, reading /proc seems to be the best way to me. At least it's much better than relying on user config files being correct. > ; after all, you can simply exec > > $login_shell in the directory you want. > > Er... what are you talking about? Sorry, that was confusion on my part. It seems the issue is not how to start the new login shell in a new tab with the desired cwd, but determining the cwd of the current shell. > Just put ". /etc/profile.d/vte.sh" in your .bashrc and you're done. That's not acceptable for existing users to be done manually. If at all, it needs to happen automatically somewhere, but automatically changing user config shell scripts can never be made robust and reliable, so that's a no-go as well. > Deal with it. Please don't ask anyone to alter the design and put significant amount of work in it just because you're lazy to place 1 line of code somewhere. This is not about me personally, but about all distro users. So "deal with it" means to me "figure out how to upgrade from gnome-terminal 3.6 to 3.14 without regressions", which is what I'm currently discussing :-) It seems you don't want to change this back to the old method upstream which is fair enough. We can do this reversion downstream, but I wouldn't want to do this before at least asking first. > Here are my arguments for the new behavior: no more dirty OS-specific digging > in proc; Digging in /proc isn't dirty at all, it's the purpose of /proc. Changing user config files is *dirty* in my POV, and should be avoided like the plague. It's impossible to do it automatically (for shell scripts) and impossible to recover from errors. Changing runtime code like /proc reading can happen at any time. > the potential of being consistent across terminal emulators Quite irrelevant. It doesn't matter how other terminal emulators behave as long as none of them rely on particular bash configs. > ability to follow symlinks Happens implicitly with /proc/pid/cwd. > ability for file managers (e.g. mc has a pending patch) to > set their working directory, while shell scripts or make-like commands > internally cd'ing won't tamper with it. That's certainly a nice thing. Nothing prevents gnome-terminal from reading an env variable and preferring that value over /proc/pid/cwd, but it shouldn't rely on it. > As far as I can see, your argument is > that it saves a one-time 10-second operation of placing something in .bashrc > (which should be done by your distribution, not by you – complain at your > distro if they haven't done it yet). You need some upgrade notification to convey that message to users, then they need to understand and not ignore it, figure out how to change it, etc. Way more than 10 seconds, a lot of them will screw it up or not do it at all, and it's a pointless "unbreak my desktop" operation. Mulitply these minutes by a few million users and you see that it's far from trivial. :-) > complain at your distro if they haven't done it yet). Well, I *am* the distro (representative) in this case :-) I noticed this morning that Ubuntu's gnome-terminal is still stuck at 3.6, asked around for the reason, and was pointed here. Anyway, you made your stanza quite clear, thank you! I mostly wanted to see how firmly you want to keep that env var approach, but we can always patch this back downstream.
(In reply to comment #45) > That's not acceptable for existing users to be done manually. Sorry, I missed that you're not a single user who manually upgraded g-t, but Ubuntu's developer updating the package. You DON'T need to update existing user's configs. You need to update /etc/profile or bashrc or zsh, whatever. > Anyway, you made your stanza quite clear, thank you! I mostly wanted to see how > firmly you want to keep that env var approach, but we can always patch this > back downstream. That was my personal opinion, I'm not sure about the main vte developer, but I find it unlikely that he'd be going backwards. Let's keep this issue at one place, downstream at Ubuntu, since we're talking about an Ubuntu issue here rather than a global gnome-terminal one: https://bugs.launchpad.net/bugs/1132700
We're not going back to reading /proc. Apart from the possible hang (of *all* terminals!), it also fixes other problems, e.g. the symlink one (which you appear to have misunderstood: it's about *not* following symlinks when opening the new tab, ie if you were in /symlink and /symlink points to /real, then the proc method will open the new tab in /real instead of /symlink), and the nested shell issue, etc. I think you have prematurely decided that reverting to the broken /proc fiddling is the only way to fix your distro's problem. vte isn't asking every user to change his ~/.bash* scripts; rather it's asking distros to source vte.sh automatically. IMO you should rather investigate why you cannot provide a way for the vte.sh script to be automatically sourced for all shells (login or non-login ones) via the default bash profile/bashrc scripts. Now debian bash maintainers seem to have rejected sourcing the /etc/profile.d/ scripts from non-login shells for no particular reason (comment 27) despite this being done by Fedora since forever (comment 30) with no apparent ill effects. You've got complete control over your distro (ubuntu), so you could either change that; alternatively if debian-derived distros were to provide a default location to install scriptlets to be sourced into non-login shells, vte would certainly install a vte.sh symlink into that location to /etc/profile.d/vte.sh.
Also, I see a rather curious inversion of priorities at play here: apparently this feature of opening new tabs in the current tab's cwd is so important that it's blocking adopting the new g-t into the distro, but on the other hand it's so unimportant that you'd rather use an approach that upstream tells you is broken, instead of investigating fixing the underlying distro issue...
> Also, I see a rather curious inversion of priorities at play here Perfect point made here, thanks ChPe :)
Hello Christian, thanks for the heads-up! (In reply to comment #47) > vte isn't asking every > user to change his ~/.bash* scripts; rather it's asking distros to source > vte.sh automatically. IMO you should rather investigate why you cannot provide > a way for the vte.sh script to be automatically sourced for all shells Lots of packages use /etc/profile.d/. But the problem is that definitions there get overwritten by ~/.bashrc, i. e. if ~/.bashrc does "export PS1=" or "export PROMPT_COMMAND=..." that rightly trumps /etc/profile.d/ (and I'm quite sure Fedora behaves the same; it would be quite a large bug if it doesn't). Our (i. e. Debian/Ubuntu's) current /etc/skel/ now doesn't set $PROMPT_COMMAND any more, it still sets $PS1; so profile.d/ scripts can never change $PS1. So using $PROMPT_COMMAND is better, but it still doesn't fix the problem for people with older home dirs who still have PROMPT_COMMAND in their ~/.bashrc (presumably from the old ages where you had to do that manually to get proper g-t tab titles). > or non-login ones) via the default bash profile/bashrc scripts. Now debian bash > maintainers seem to have rejected sourcing the /etc/profile.d/ scripts from > non-login shells for no particular reason (comment 27) despite this being done > by Fedora since forever (comment 30) with no apparent ill effects. That might be another behaviour difference indeed. However, /etc/profile.d/bash_completion.sh and /etc/profile.d/appmenu-qt5.sh obviously work in current Ubuntu in gnome-terminal, so this doesn't seem to be generally broken. So if that prevents sourcing of profile.d/vte.sh that's certainly worth fixing as well, although it still doesn't fix the problem of overwriting in ~/.bashrc completely.
(In reply to comment #50) > but it still doesn't fix the problem for > people with older home dirs who still have PROMPT_COMMAND in their ~/.bashrc > (presumably from the old ages where you had to do that manually to get proper > g-t tab titles). So you're degrading g-t experience for most of the users, for the benefit of those few who have previously tampered with their bashrc yet would prefer not to do that again? If you really-really-really insist on out-of-the-box solution for those few users, please do the following: 1. source vte.sh, make it work for every new user the way we recommend 2. if a terminal instance has already seen an OSC 7 sequence, use that value as the base directory for new terminals 3. if a terminal instance has never encountered an OSC 7, then revert to the old method of getting the directory from /proc 4. do manual tests to ensure that the 3rd code path is not executed for newly created users who don't alter their bash/zsh settings.
> So you're degrading g-t experience for most of the users Well, at the moment we don't, as Ubuntu currently still has g-t 3.6. I wondered about that this morning and asked around what the reason was. At the moment that feature is working quite well, after all. As written in the downstream bug I'm willing to look into the impact of moving to env vars, but this is still so much more complicated and intrusive than simply reading cwd from /proc, and that's why I asked about the reasons. I'm still not really convinced that vte.sh is better than /proc, but at least we now have some alternatives to consider. At least this "blocked and ignored for many months" situation has made some advancement, so thanks for the discussion!
(In reply to comment #51) > 3. if a terminal instance has never encountered an OSC 7, then revert to the > old method of getting the directory from /proc Indeed, this is a great compromise. I. e. fall back to /proc if the env var isn't set, to avoid regressions with existing ~/.bashrcs which redefine the vars.
Created attachment 288524 [details] [review] Provide fallback for reading current directory if OSC 7 fails As discussed here and in the Ubuntu downstream bug, this implements the compromise: We continue to primarily use profile.d/vte.sh's $PROMPT_COMMAND, and only fall back to reading /proc if that fails. cwd_of_pid() is mostly taken from upstream commit cf3cad, with two differences: - I dropped querying priv->pty_fd as that got removed; also, querying the primary child (i. e. the shell) seems just fine to me, as that's the process whose cwd we expect for a new tab. - The old g_snprintf() was causing a compiler error with at least gcc 4.9: terminal-screen.c:224:7: error: format not a string literal, argument types not checked [-Werror=format-nonliteral] So this patch silents the warning for this call, as it's legitimate (we know that patterns[i] is a proper format string). I know that you are reluctant to bring this back upstream. I'm fine with applying it in Debian/Ubuntu only, but I still want to put it here for full disclosure. I also think it still does make sense to be applied upstream, as the reasons for it are not really Debian/Ubuntu specific. Thanks for considering!
A minor issue with your patch: Emit OSC 7 to /tmp/symlink, open a second tab that does not emit OSC 7 (it is in /tmp/symlink), from the second tab open a third one, it'll be in /tmp/real. I'm not sure if anything can be done against this, after all, if OSC 7 is not issued then g-t has no notion about whether the directory changed back-and-forth or changed from /tmp/symlink to /tmp/real or didn't change at all. And if your prompt sets OSC 7 then it won't occur. One thing you could do is to check whether the result of querying /proc and screen->priv->initial_working_directory refer to the same physical directory, and in that case use the (potentially symlink) screen->priv->initial_working_directory. It's really low prio, though, and still not a perfect solution. > I also think it still does make sense to be applied upstream, as the reasons for it are not really Debian/Ubuntu specific. In my personal opinion, it is better to drop the legacy crap, have a cleaner code and force some users to update their configs to get a better solution, rather than helping them remain stuck with a worse version for many more years. The situation is indeed not Debian/Ubuntu-specific per se. Someone jumping from g-t 3.6 to 3.16 without using any versions in between is way more likely to happen primarly to Ubuntu users. Users of all other distros have probably already updated their configs if they cared about this issue. In my opinion, keeping this workaround would have probably made sense if it was shipped straight in 3.8 so that this feature didn't break for anyone. Now that 4 consecutive major versions were released without this compatibility hack, I see absolutely no point in bringing it back.
That being said, thanks a lot for taking care of the Ubuntu package! Seems like your patch might be a reasonable thing to do for that distro, if you're really so worried about your users from the Hardy era.
Yeah, I suspected that. Sorry for bringing this up so late, I really only noticed that Ubuntu is still on 3.6 by accident a week or so ago.
Comment on attachment 288524 [details] [review] Provide fallback for reading current directory if OSC 7 fails Doing some status cleanup. I think we discussed this enough now, I see little point of keeping this open still. Thanks!
(In reply to comment #56) > Seems like > your patch might be a reasonable thing to do for that distro, if you're really > so worried about your users from the Hardy era. For what it is worth, I have come across the occasional Fedora user, who has touched PROMPT_COMMAND in his startup scripts, getting bitten by this issue.
(In reply to comment #59) > For what it is worth, I have come across the occasional Fedora user, who has > touched PROMPT_COMMAND in his startup scripts, getting bitten by this issue. Yup, sure... but I bet gnome-terminal vs. PROMPT_COMMAND is not the only place you've seen such behavior, right? I mean, old C++ source codes stop compiling at pretty much every gcc upgrade, shell scripts break at major bash updates, something breaks at pretty much every Gnome update etc. I think it's fair game that if someone has ever explicitly set PROMPT_COMMAND (that is, not appended/prepended to it but overridden it) then they might need to update it. If we really wanted to make it foolproof, an idea to consider would be to hardwire emitting OSC 7 into bash/zsh (behind a new flag, e.g. "shopt -s cwd_osc7") rather than relying on vte.sh/PROMPT_COMMAND to do this. It would be really cool if mainstream bash/zsh developers accepted this feature.
... And, distros should stop shipping anything under /etc/skel. They should patch/configure all their software to work as desired with an empty user config, for the very reason that the copies of those files under the users' home dirs are later unmaintainable.
(In reply to comment #61) > ... And, distros should stop shipping anything under /etc/skel. They should > patch/configure all their software to work as desired with an empty user > config, for the very reason that the copies of those files under the users' > home dirs are later unmaintainable. Big +1 :-)
(In reply to Egmont Koblinger from comment #60) > (In reply to comment #59) > > For what it is worth, I have come across the occasional Fedora user, who has > > touched PROMPT_COMMAND in his startup scripts, getting bitten by this issue. > > Yup, sure... but I bet gnome-terminal vs. PROMPT_COMMAND is not the only > place you've seen such behavior, right? I mean, old C++ source codes stop > compiling at pretty much every gcc upgrade, shell scripts break at major > bash updates, something breaks at pretty much every Gnome update etc. I > think it's fair game that if someone has ever explicitly set PROMPT_COMMAND > (that is, not appended/prepended to it but overridden it) then they might > need to update it. The problem is that it's not obvious to the user that PROMPT_COMMAND has any special significance to the terminal emulator. It's not unreasonable to expect the terminal emulator and the shell to work together to do certain things, just like a graphical display environment co-ordinates with the GUI toolkit for certain things. So, in that sense VTE using PROMPT_COMMAND is fine. However this being the command-line, and PROMPT_COMMAND widely advertised as one of the ways for the user to customise their Bash, it ends up being a trap. In an ideal world, the shell should provide separate hooks for the user to customise and the terminal emulator to plug into, with clear semantics about how they interact with each other. However, I don't see that happening unless other other terminal developers raise this issue with the shell folks. In the meantime, I wonder if we can do better than just having an entry in the FAQ [1]. [1] https://wiki.gnome.org/Apps/Terminal/FAQ
> In the meantime, I wonder if we can do better than just having an entry in > the FAQ Depends on what that "we" stands for. :) If it's "we, GNOME developers" then there isn't too much we could do, or at least there isn't a clean solution (we could go for somewhat ugly hacks, as e.g. bug 704960 comment 24). If it's "we, Red Hat / Fedora developers" then sure, just make sure every interactive shell sources vte.sh on startup, and feel free modify the script however you feel it's best fit with the distro. See https://gitlab.gnome.org/GNOME/vte/issues/37 for a recent discussion. It would be cool if Fedora could be the leading distro here showing others how to do it properly. Can you help us here, including necessary modifications to bash's startup scripts?
Fedora already doesn't differentiate between login and non-login shells with respect to /etc/profile.d. So, there's nothing to do in that respect. Or did I misunderstand? Since PROMPT_COMMAND is needed by upstream gnome-terminal and VTE, a broken environment arising from its absence should also be handled upstream. For example, we can send a notification or a log a WARNING to the journal, if we know that the user is running their default shell and vte_terminal_get_current_directory_uri is NULL.
(In reply to Debarshi Ray from comment #65) > Fedora already doesn't differentiate between login and non-login shells with > respect to /etc/profile.d. So, there's nothing to do in that respect. Or did > I misunderstand? Nope, it's that I'm using Ubuntu and I'm not familiar with Fedora's solutions. Good to hear that it's solved there! > Since PROMPT_COMMAND is needed by upstream gnome-terminal and VTE, a broken > environment arising from its absence should also be handled upstream. I'm a little bit lost... is the issue now that the necessary functionality for preserving CWD isn't achieved? If so, why? Or are we talking about vte.sh wiping out previous contents of PROMPT_COMMAND? Would, instead of talking about the philosophical side of the story, just making sure that we _append_ to PROMPT_COMMAND solve _everything_ for Fedora? If so, I'm happy to do that (even though it wouldn't solve it in other distros)!
If the bash maintainers cannot be persuaded to make PROMPT_COMMAND etc. an array in code (or provide an array as an alternative), the distribution's default bash configuration could work around that by something like my proposal in https://bugzilla.redhat.com/show_bug.cgi?id=924275#c13 . For other things, like reliable integration with job control (recent discussion in bug 711059), that's not possible (using hacks like DEBUG trap poking at internal is not a solution); a distribution patch for bash would need to be developed, even it won't be upstream. As I said in comment 47, distributions have full control over their bash configuration scripts. They can source /etc/profile.d scripts on all shells (login and non-login), and gnome-terminal/vte should not be asked to work around distribution's unwillingness to do so. I would love for bash (and others, like readline, terminfo/ncurses) to have the necessary integration with vte (and other terminal emulators), but if the bash/etc maintainer(s) doesn't like these features, that would mean forking and maintaining that fork. I don't think we have the resources for that.
(In reply to Egmont Koblinger from comment #66) > (In reply to Debarshi Ray from comment #65) > > Since PROMPT_COMMAND is needed by upstream gnome-terminal and VTE, a broken > > environment arising from its absence should also be handled upstream. > > I'm a little bit lost... is the issue now that the necessary functionality > for preserving CWD isn't achieved? If so, why? Or are we talking about > vte.sh wiping out previous contents of PROMPT_COMMAND? Would, instead of > talking about the philosophical side of the story, just making sure that we > _append_ to PROMPT_COMMAND solve _everything_ for Fedora? If so, I'm happy > to do that (even though it wouldn't solve it in other distros)! I am referring to comment 59 The fact of the matter is: (a) gnome-terminal and VTE expect OSC 7 to be emitted from it (b) PROMPT_COMMAND is advertised to users as a way to customise their Bash, so they have no idea about (a) unless they have read the FAQ So, regardless of how vte.sh modifies PROMPT_COMMAND, users can still overwrite it and break gnome-terminal. This happens, and the FAQ isn't first place they look. They think their terminal broke and it's not clear why.
(In reply to Debarshi Ray from comment #68) > So, regardless of how vte.sh modifies PROMPT_COMMAND, users can still > overwrite it and break gnome-terminal. This is an aspect of the story that hasn't occurred to me. > This happens Does it really? Could you please give pointers? Honestly, if a user wipes out a previous value from PROMPT_COMMAND, it's their fault. I can't really see a way of protecting against this. If we put our stuff in PS1, they'd modify PS1 and see this feature being gone. If we place our stuff in the debug trap, users who set up a debug trap will break this. A clean approach could be if bash and zsh introduced a new shopt (or whatever equivalent zsh has), which when enabled would emit OSC 7 (with proper URI escaping) on its own. I haven't tried, but I don't see too much chance of being able to convince bash's developer on my own.
(In reply to Christian Persch from comment #67) > As I said in comment 47, distributions have full control over their bash > configuration scripts. They can source /etc/profile.d scripts on all shells > (login and non-login), and gnome-terminal/vte should not be asked to work > around distribution's unwillingness to do so. Sure, but I am talking about the terminal asserting it's requirements from the environment at run-time. If the terminal needs to function among such intransigience, then it might as well make its displeasure more visible. :)
> If the terminal needs to function among such intransigience, then it might as well make its displeasure more visible. :) gnome-terminal doesn't _need_ this feature. It's a convenience user feature. I've even heard about a user who didn't like it and wanted to disable. IMHO to warn in this case is just a (low priority, and by the way cumbersome to implement) feature request.
(In reply to Egmont Koblinger from comment #69) > (In reply to Debarshi Ray from comment #68) > > > So, regardless of how vte.sh modifies PROMPT_COMMAND, users can still > > overwrite it and break gnome-terminal. > > This is an aspect of the story that hasn't occurred to me. > > > This happens > > Does it really? Could you please give pointers? You mean examples of cases why a user might do that? I typed "PROMPT_COMMAND" in Google and this was one of the hits: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x264.html I am sure there are others. eg., to set a cute prompt reflecting the development environment, etc.. I don't encounter this very often, but every once in a while I do run across somebody who wiped out PROMPT_COMMAND and didn't realize why their terminal broke. > Honestly, if a user wipes out a previous value from PROMPT_COMMAND, it's > their fault. I can't fault users for tinkering with a widely advertised Bash setting. Among the dozens (hundreds?) of pages on the Internet showing how to customize Bash by tweaking PROMPT_COMMAND, I am yet to see one that warns about negative side-effects like breaking the terminal. > I can't really see a way of protecting against this. If we put > our stuff in PS1, they'd modify PS1 and see this feature being gone. If we > place our stuff in the debug trap, users who set up a debug trap will break > this. That's why I wrote in comment 63: "In an ideal world, the shell should provide separate hooks for the user to customise and the terminal emulator to plug into, with clear semantics about how they interact with each other."
I think we're on the same page, then. Do you feel like filing a bash and zsh feature request for a new shopt, to emit osc7? :) I'd love to see this feature getting implemented in popular shells.
Just to note that it needs to be carefully considered when to report cwd changes. Only interactive shells should do so; things like subshells "(cd foo && ./bar)" should *not*.
Maybe we should at least make a list of features we want from the shell, with exact specification they need to fulfill for our purposes, so we know *what* we're arguing for in discussion with the maintainers.