vte.sh sets PROMPT_COMMAND, which might already exist; it should instead
append to PROMPT_COMMAND.  Patch attached.

- Josh Triplett

forwarded 714175 https://bugzilla.gnome.org/show_bug.cgi?id=704960
thanks

Dear submitter,

as the package vte3 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/807568

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)

Hey.

Regarding this issue...

What upstream currently plans to do (see
https://gitlab.gnome.org/GNOME/vte/-/issues/37 ) still breaks an
existing PROMPT_COMMAND, unless it exists already as a variable.

See my comments about the situation in:
[0] https://gitlab.gnome.org/GNOME/vte/-/issues/37#note_1280913


I've independently proposed another way how to handle this in:
https://gitlab.gnome.org/GNOME/vte/-/issues/2502
respectively:
https://gitlab.gnome.org/calestyo/vte/-/commit/06431d0ea7e8d27f95bbeda933958ba29043e19e

Which, AFAICS, handles all (realistic) cases properly with bash
versions that support PROMPT_COMMAND as an array (that is: all versions
Debian currently has since buster).

Realistic refers to the fact, that a user might do weird things, like
using name refs or defining PROMPT_COMMAND an associative array... but
for the former it may even work, and for the latter PROMPT_COMMAND
itself doesn't work at all as an associative array.
So that shouldn't be a problem.


I should note however that upstream rejected my proposed patch:
https://gitlab.gnome.org/GNOME/vte/-/issues/2502#note_1203193

But I don't really understand why. Their arguing seem to be that they
want to add another command to PROMPT_COMMAND depending on whether it's
an array or not:
- if it is an array, add a command that only handles OSC7
- if it's not, add one that does both OSC7 and window titles

As I discuss in [0], this doesn't make sense (or I just don't
understand it ^^).
But anyway... in Debian, window titles are anyway handled by bashrc's
setting of PS1.



Cheers,
Chris.


btw: OSC7 has IMO anyway security implications:
https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20#note_956242

So IMO it should be anyway disabled in the code (wouldn't be enough to
disable the profile.d script)

I think these were just set because of the old bugzilla entry having
been closed.