Description of problem:
Spurious output in bash e.g.,
  [rharley@research0 ~]$ echo Foo
  rharley009D777;preexecrharley009CFoo
  [rharley@research0 ~]$ 

Version-Release number of selected component (if applicable):
bash-5.0.11-1.fc31.x86_64
vte-profile-0.58.3-1.fc31.x86_64

How reproducible:
Always on my setup.

Steps to Reproduce:
1. Launch terminal in desktop.

Actual results:
Spurious output on every command.

Expected results:
Clean output.

Additional info:
The script /etc/profile.d/vte.sh is setting:
  PS0=$(printf "\u009D777;preexec\u009C")
Here the \u009D and \u009C should presumably be interpreted as UTF escape sequences,
but instead the \u part is being expanded into the username.

Hello,

The problem is caused by https://src.fedoraproject.org/rpms/vte291/blob/master/f/vte291-cntnr-precmd-preexec-scroll.patch and we are also suffering it in Gentoo as we apply it:
https://bugs.gentoo.org/715526

I think this bug should then be reassigned to vte291 component instead of bash

Thanks

Isn't this similar to https://bugzilla.redhat.com/show_bug.cgi?id=1783802 ?

At least in my case we are using in Gentoo the latest patch using PS0=$(printf "\033]777;preexec\033\\") and I get the problems with it :/

$ set |grep PS0
PS0=$'\E]777;preexec\E\\'
$ set |grep PS0
mandPS0=$'\E]777;preexec\E\\'
$ set |grep PS0
tionPS0=$'\E]777;preexec\E\\'

For example, if I set it back to the C1 controls, it doesn't show the issue:
PS0=$(printf "\u009D777;preexec\u009C")

but with
PS0=$(printf "\033]777;preexec\033\\")

I get this bug :/

Reading the bug https://bugzilla.redhat.com/show_bug.cgi?id=1783802 again probably this is the issue referred in the first comment about spurious characters that lead to the use of C1 controls to be used instead, but I don't know how to solve it and what is wrong with the escapes

It seems to work with :
PS0=$(printf "\033]777;preexec\033]\\")

(appending ] after the second 033), but I don't know if it's correct :)

But later commands like "su -" don't return :S, then that is not ok

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Closing this bug as I am not able to reproduce it with Fedora 34.