Bug 1805323

Summary:	Bash and/or vte-profile mishandling PS0 in Fedora 31
Product:	[Fedora] Fedora	Reporter:	r3obh <Robert.Harley>
Component:	bash	Assignee:	Siteshwar Vashisht <svashisht>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	admiller, alexander, debarshir, kasal, kdudka, pachoramos1, ssbarnea, svashisht
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-01 11:38:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description r3obh 2020-02-20 16:41:44 UTC

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 r3obh 2020-02-20 16:48:13 UTC

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.

Comment 2 Pacho Ramos 2020-04-01 07:51:17 UTC

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

Comment 3 Debarshi Ray 2020-04-03 12:06:02 UTC

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

Comment 4 Pacho Ramos 2020-04-03 18:58:06 UTC

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\\'

Comment 5 Pacho Ramos 2020-04-04 17:27:12 UTC

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 :/

Comment 6 Pacho Ramos 2020-04-04 17:30:17 UTC

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

Comment 7 Pacho Ramos 2020-04-04 17:42:31 UTC

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 :)

Comment 8 Pacho Ramos 2020-04-04 17:52:05 UTC

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

Comment 9 Ben Cotton 2020-08-11 13:09:14 UTC

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

Comment 10 Siteshwar Vashisht 2021-11-01 11:38:07 UTC

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