Bug 1183192
| Summary: | vte-profile's vte.sh overrides any earlier setting of PROMPT_COMMAND (and duplicates /etc/bashrc) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | DO NOT USE account not monitored (old adamwill) <adamw+fedora> | ||||
| Component: | vte291 | Assignee: | Debarshi Ray <debarshir> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 35 | CC: | alick9188, awilliam, ced, chpe, debarshir, dgunchev, egmont, garrett.mitchener, jtudelag, kalevlember, klember, lzachar, samuel.rakitnican, uvsmtid | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2022-06-15 19:57:44 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: | |||||||
| Attachments: |
|
||||||
Re "Second": See https://bugzilla.gnome.org/show_bug.cgi?id=704960 , I'll fix it for the next release. The (bogus) /etc/bashrc change comes from bug 924275. And it's done in vte.sh because vte.sh is upstream, while /etc/bashrc is fedora specific. In bug 924275 comment 13 I had proposed a way to make this work nicely, but it wasn't well-received. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Still present in Fedora 23. $ rpm -q vte291 vte-profile vte291-0.42.3-1.fc23.x86_64 vte-profile-0.42.3-1.fc23.x86_64 Christian: the failure to incorporate previously set PROMPT_COMMAND seems like a problem specific to vte that can be fixed without anyone else's say-so... Still in Fedora 24. This gets in the way of autojump. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Created attachment 1181684 [details] proposed fix VTE is overwriting system ENV variable, this is then a vte bug as I see it. IMHO it should be either fixed or removed because it _breaks_ ENV variable. It should be fixed at least temporarily by appending its stuff to the PROMPT_COMMAND and not overwriting, and again IMHO. I don't think it should be removed since the fix is so simple as I see it. As said by autojump developer: > For bash users, autojump keeps track of directories by modifying $PROMPT_COMMAND. Do not overwrite $PROMPT_COMMAND: > > export PROMPT_COMMAND="history -a" > > Instead append to the end of the existing \$PROMPT_COMMAND: > > export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ;} history -a" And this seems as right fix to me. This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'. So, why can't we have this: https://bugzilla.redhat.com/show_bug.cgi?id=924275#c13 ? Other than handwaving it away as "playing with arrays for PROMPT_COMMAND seems to be over-engineering". To be honest, if Bash or the Fedora start-up script maintainers really don't want the terminal emulator to override global environment variables, then they should try harder to offer suitable facilities. If its considered "over-engineering", then why should vte bother? (In reply to Debarshi Ray from comment #11) > To be honest, if Bash or the Fedora start-up script maintainers really don't > want the terminal emulator to override global environment variables, then > they should try harder to offer suitable facilities. If its considered > "over-engineering", then why should vte bother? Hi, I am not sure what you mean, but the way I see it, bashrc is not overwriting PROMPT_COMMAND variable: # are we an interactive shell? if [ "$PS1" ]; then if [ -z "$PROMPT_COMMAND" ]; then case $TERM in But vte.sh is: case "$TERM" in xterm*|vte*) [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" I think vte should stop doing this. This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. PROMPT_COMMAND override, IMO, is clearly intrusive.
It's even more annoying when all it seems to solve are:
1. "Command completed" notification for Gnome shell.
2. New tab is opened in the same directory as the existing tab.
...
Is there something else?
For example, for `tmux` users, both points become irrelevant.
I tried to `dnf erase vte-profile` but it got itself as dependency
for many important packages (directly or indirectly).
More over, `/etc/profile.d/vte.sh` is the only file `vte-profile` package provides.
Solution:
Shouldn't solution for Fedora be in simple RPM-dependency fix?
What if it can become completely optional?
For example:
It could be included by default with GNOME
(with all other stuff like `gedit).
But if you uninstall it, it erases itself only.
Otherwise (fixing it on `vte.sh` side) is blocked by resistance:
https://bugzilla.gnome.org/show_bug.cgi?id=704960
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. I don't see any change in vte.sh in current Rawhide. The upstream bug seemed to get into an argument and then be abandoned... IMO Fedora should patch vte.sh for now since upstream does not think there is urgent need of fixing this. But is the package owner still actively maintaining the package? This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30. This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Still seeing similar vte.sh in Fedora 32 This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Still appears to be the case in Rawhide. Nothing has changed. upstream bug is still stuck in an argument in 2017. Can someone please revisit this and do something about it finally? Sorry, I don't know anything about this, this is all downstream patches that Rishi maintains. This has nothing to do with fedora's vte patches; this is upstream. -> https://gitlab.gnome.org/GNOME/vte/-/issues/37 . Since bash apparently now has the required functionality, someone can submit a patch to vte to use it. This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35. This is fixed upstream since vte 0.66 (see https://gitlab.gnome.org/GNOME/vte/-/issues/37) but the distribution's setup needs changes for this, too (see the upstream bug). This bug, as originally reported has two parts. (In reply to Adam Williamson (Fedora) from comment #0) > /etc/bashrc has this: > > case $TERM in > xterm*|vte*) > if [ -e /etc/sysconfig/bash-prompt-xterm ]; then > PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm > elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then > PROMPT_COMMAND="__vte_prompt_command" > else > PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" > "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"' > > then /etc/profile.d/vte.sh has: > > case "$TERM" in > xterm*|vte*) > [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" > [ -n "$ZSH_VERSION" ] && precmd_functions+=(__vte_osc7) > ;; > esac > > first of all, why is this duplicated between the two? Seems unnecessary. This first part has been effectively fixed since Fedora 35 because it was negatively impacting certain Toolbx containers: https://pagure.io/setup/pull-request/23 ... and I filed a clean-up as a follow-up: https://pagure.io/setup/pull-request/37 (In reply to Adam Williamson (Fedora) from comment #0) > > Second, vte.sh doesn't incorporate any previous PROMPT_COMMAND. That means > if you create a /etc/profile.d/prompt.sh (for e.g.) and set a custom > PROMPT_COMMAND in it, it doesn't work, because vte.sh is included later and > overrides it. You have to name your file so it comes alphabetically after > vte.sh if you want to set a custom PROMPT_COMMAND. As far as VTE is concerned, the second part was fixed in GNOME 41 (ie., Fedora 35 timeframe) (see comment 27): https://gitlab.gnome.org/GNOME/vte/-/issues/37 ... because Bash 5.1 made it possible to use PROMPT_COMMAND as an array: https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003.html That's essentially what we (as in GNOME) had long asked for. See comment 2, comment 10 and comment 11. However, VTE can only use PROMPT_COMMAND as an array if Fedora's Bash start-up scripts declare PROMPT_COMMAND as an array. Currently that's not the case, and we need to get that done in 'setup'. I am going to close this as CURRENTRELEASE, because this bug is against Fedora 35, and as far as VTE is concerned, barring clean-ups, it's fixed since F35. Please file a bug against 'setup' to switch PROMPT_COMMAND to an array, and CC me. Or, I may eventually end up submitting a pull request. :P |
/etc/bashrc has this: case $TERM in xterm*|vte*) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then PROMPT_COMMAND="__vte_prompt_command" else PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"' then /etc/profile.d/vte.sh has: case "$TERM" in xterm*|vte*) [ -n "$BASH_VERSION" ] && PROMPT_COMMAND="__vte_prompt_command" [ -n "$ZSH_VERSION" ] && precmd_functions+=(__vte_osc7) ;; esac first of all, why is this duplicated between the two? Seems unnecessary. Second, vte.sh doesn't incorporate any previous PROMPT_COMMAND. That means if you create a /etc/profile.d/prompt.sh (for e.g.) and set a custom PROMPT_COMMAND in it, it doesn't work, because vte.sh is included later and overrides it. You have to name your file so it comes alphabetically after vte.sh if you want to set a custom PROMPT_COMMAND.