If I load . /etc/profile.d/vte-2.91.sh in my .bashrc I get strange characters sometimes, like: bash: ll: no se encontró la orden pacho@dell-2017 ~ $ ll bash: ll: no se encontró la orden pacho@dell-2017 ~ $ ll chobash: ll: no se encontró la orden pacho@dell-2017 ~ $ ll chobash: ll: no se encontró la orden pacho@dell-2017 ~ $ ll chobash: ll: no se encontró la orden pacho@dell-2017 ~ $ ll I refer to that "cho" before "bash...." it looks to be caused by a Fedora patch (that we apply in Gentoo too): https://www.linuxquestions.org/questions/linux-software-2/ps1-prompt-inserts-text-777%3Bpreexec-4175665604/ https://github.com/TragicWarrior/libvterm/issues/147 https://github.com/alacritty/alacritty/issues/3105 https://bugzilla.redhat.com/show_bug.cgi?id=1780785 https://slashnix.com/linux/how-to-remove-the-return-code-from-the-terminal-prompt-in-centos-7/ -> https://bugzilla.redhat.com/show_bug.cgi?id=1805323 But I don't know how to fix the escapes in the resulting vte.sh file :/ Merging vte with USE "vanilla" fixes the problem as it doesn't apply Fedora patch
This are the differences between vte.sh from 0.56 (that worked) and 0.58 --- vte-2.91.sh 2020-04-01 13:47:59.604843818 +0200 +++ /etc/profile.d/vte-2.91.sh 2020-04-01 13:48:52.537482004 +0200 @@ -54,12 +54,13 @@ command="${command//;/ }" local pwd='~' [ "$PWD" != "$HOME" ] && pwd=${PWD/#$HOME\//\~\/} - printf '\033]777;notify;Command completed;%s\033\\\033]0;%s@%s:%s\033\\%s' "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)" + pwd="${pwd//[[:cntrl:]]}" + printf '\033]777;notify;Command completed;%s\033\\\033]777;precmd\033\\\033]0;%s@%s:%s\033\\%s' "${command}" "${USER}" "${HOSTNAME%%.*}" "${pwd}" "$(__vte_osc7)" } case "$TERM" in xterm*|vte*) - [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" + [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" && PS0=$(printf "\033]777;preexec\033\\") [ -n "$ZSH_VERSION" ] && precmd_functions+=(__vte_osc7) ;; esac The + pwd="${pwd//[[:cntrl:]]}" is an upstream change, the others are from Fedora patch updates, but I have checked their latest patch and it seems we are using the same as them
Any idea how I can reproduce this? Doesn't happen here
Well, before knowing it was a problem with Fedora patch I reported to vte upstream, https://gitlab.gnome.org/GNOME/vte/-/issues/224 There I attached the output with script: https://gitlab.gnome.org/GNOME/vte/uploads/dc356765bed174e0f39491bf48496a7a/typescript I tried also with a simple .bashrc as the one I pasted in the bug report to discard it was caused by other things in my .bashrc. With that simple .bashrc I got all the script log. I think I don't have anything more special, my .bash_profile contains only: # This file is sourced by bash for login shells. The following line # runs your .bashrc and is recommended by the bash info pages. [[ -f ~/.bashrc ]] && . ~/.bashrc And I have no .profile in my home :/ It is usually noticeable after multiple commands are run on a terminal. I tested it with gnome-terminal and vte terminal
and PS0 has this value for me: $ set |grep PS0 PS0=$'\E]777;preexec\E\\' that leads to: $ echo $PS0 $ echo $PS0 7 $ echo $PS0 mand $ echo $PS0 tion $ echo $PS0 tion
*** Bug 718674 has been marked as a duplicate of this bug. ***
(In reply to Mart Raudsepp from comment #2) > Any idea how I can reproduce this? Doesn't happen here In x11-terms/mate-terminal and x11-terms/guake it happens if "Run command as login shell" checkbox is checked in Profile Preferences.
I was able to fix this issue by replacing this PS0=$(printf "\033]777;preexec\033\\") with this PS0=$(printf "\u009D777;preexec\u009C") The inspiration came this bug [1]. Note that in that bug, the are talking about going the opposite direction. I suspect that the version /etc/profile.d/vte-2.91.sh that is installed by x11-libs/vte-0.58.2[-vanilla] is for a newer version of vte and my suggestion above will not work for these newer versions of vte. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1783802
i hate you fedora, this gave me nightmares during the day time. @sam_c was nice enough to point me here love you all for the salvation
It's just stol^Wborrowed from Fedora for some very useful features it provides. That's how we have long-running command completion desktop notifications, "Set title" still possible for a tab, transparent background possibility and much more. vte-2.91.sh is shipped by the same vte package, so they shouldn't be out of sync, unless you have your own vte.sh somewhere that's sourced instead. What should be done here is the patchset compared with their 3.36 patchset - maybe the issue is already fixed there and we can backport. Meanwhile I kept the 3.32 around of vte/gnome-terminal on purpose until this is figured out.
Good news: I cannot reproduce this bug anymore after upgrading bash from 4.4 to 5.0
Also I cannot reproduce this bug with vanilla bash-5.0. So it's hard to find how to fix this issue in bash-4.4 since bash lacks a proper commit history.
Did you try my suggestion from #c7 with bash 5.0? It seem to work just fine in my system with bash 4.4.23 (the current stable).
(In reply to redneb from comment #12) Fedora switched from C1 to C0 controls for reason. There are people who launch terminals that doesn't support C1 controls from VTE-based terminals.
Has anyone hit the issue anymore with bash-5, which is by now stable on amd64 per dependent bug?
I think it's solved
Alright. Bash stabilization is only missing hppa now, but we don't have stable vte on hppa, so should be all good then.
