Fixed.

I don't agree with this. vte.sh only sets the title in bash because that was the only way I could get it to work with the existing distro's bashrc scripts. In zsh, we can just *add* our osc7 function to the prompt commands, and leave the title to the distro to set however they wish.

It's the inconsistency that bothers me the most - why do we offer a different experience by default to users of those two shells?

> In zsh, we can just *add* our osc7 function to the prompt commands, and leave
> the title to the distro to set however they wish.

Actually this would be my preferred behavior. I don't think a terminal emulator should decide what the user should see in the title by default. In my opinion, it should be a decision made (and implementated) by distributions.

For zsh, vte does half the work and you let distros do the other half if they wish to. You argue that it's the right approach, and I totally agree. However, we could just as easily do this with bash.

First, we can just append ocs7 to PROMPT_COMMAND, and let the distro append the title change if they wish to, just as they'd do for zsh. Just because it's technically uglier (append to a string with a ";" separator, rather than append to the array) it's still just as easy to do.

Second, even if it wasn't possible, distros could still just as easily patch our script. For a distro it's not any harder to write/maintain a small patch than to write/maintain an additional script which cooperates with the rest.

It'd be totally up for reverting this change, and changing bash too to set osc7 only! Distros can damn easily for both shells add setting title too if that's what they want.

Reverted the commit.

Neither of us was fully satisfied with the new version, and I wouldn't want distros to see it change twice (once after tomorrow's release, and once later again).

I'd like to go for a solution where vte.sh doesn't do anything with the window title.

See also https://bugzilla.gnome.org/show_bug.cgi?id=697475#c19 for an explanation of the order of startup scripts in fedora, which means that we cannot not make PROMPT_COMMAND use the title sequence.

I agree that PROMPT_COMMAND is the right place to set the title -- if that's what someone wants to do.  I firmly disagree that it should be vte's decision whether to do this, and still if the decision is "yes", I firmly disagree that vte should implement it.

If Fedora decides they'd like to see the cwd in the title, they should create another /etc/profile.d/title.sh or something like this, which appends it to PROMPT_COMMAND -- presumably not only for vte.  And vte appends osc7.  These two would be executed in any order, and it'd be fine.

-o-o-o-

Let's make one step backwards and look at the whole global picture rather than the details.  (I'm talking about both this bug and its "sibling" bug now.)

The reason this script exists is because osc7 replaced digging into /proc.  The intent was to do only this.  Title just came in becase of mainstream bash's decision that a prompt command array is an overkill instead of just appending multiple commands separated by a ';', because Fedora folks didn't like your nice idea of implementing this (I can't understand why), and because you were reluctant to go for the semicolon (I can't understand this one either).

Fedora's scripts were messy.  Vte.sh came and provided a hackish workaround for Fedora, that one particular distribution, not caring about others.  Then it still wasn't good enough for them, and they (without any coordination with us) copied this vte-specific code to /etc/bashrc.  There are multiple bugreports in various distros that our script is not good; including the most recent one from someone at Fedora.

It's workaround on top of a workaround and then another workaround, each time everything getting more complicated and messier, plus lack of cooperation between the two teams.  We make something for them, it's not good enough for them so they silently change it, and then it's even harder for us to change anything because ohmygod we'd break them.  It's a neverending story.

They have modified their scripts multiple times.  They are able to, and will do if we push them.  For zsh you had the approach that distros should finish our work according to their preference.  For bash you insist on something that'd work out of the box, even though they could just as easily tailor their system.

We don't always please Fedora out of the box.  They want transparency, we don't include it.  They prefer dark theme, we just made it harder for them.  Vte.sh isn't fully good for them either.  I don't see why vte.sh would need to fully please them, and in the mean time ignore other distros; rather than shipping something generic.

It's unclear what vte.sh tries to do, it's unclear why it wants to do, the responsibility split between the two functionalities (osc7 vs title) is unclear, the responsibility split between the two teams/software (gnome vs redhat) is unclear, and each time it's getting more complicated.  I hate this route.  And I hate that we have one particular distro in mind, create something hackish for them, let alone that it's still not good enough for them either.

The only way I can see out of this situation is to stop this madness for good, and go for the only clean solution.

The only clean solution I can see is:  Draw the line of responsibility.  Setting osc7 is our job, setting the title is not, it's the distro's, should they want it.  Ship a script that does what we want to do (that is: osc7 only), and do it in the simplest possible way that's flexible enough not to cause any problems (that is: append to PROMPT_COMMAND).

This might break the title in Fedora for a few days.  They will notice it, their users will notice it, we can also explicitly notify them.  They will figure out how they solve it.  E.g. by another script under /etc/profile.d which appends to PROMPT_COMMAND.  It's their job, not ours, and it's really not that hard.

Let's do that early next cycle (3.17.0) then.

I don't see the point in waiting, but if that's the compromise, I'm game! :)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2158.