Bug 1215792 - mock PROMPT_COMMAND setting causing strange cursor behavior
Summary: mock PROMPT_COMMAND setting causing strange cursor behavior
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-27 17:53 UTC by Martin Sebor
Modified: 2017-08-08 11:57 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-08-08 11:57:17 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1183733 0 unspecified CLOSED Weird "<mock-chroot>sh-4.3#" prompt 2021-02-22 00:41:40 UTC

Internal Links: 1183733

Description Martin Sebor 2015-04-27 17:53:53 UTC
When the mock --shell command starts a shell in a chroot it arranges for the PROMPT_COMMAND Bash variable to be set to the 'printf "<mock-chroot>"' string and the PS1 variable to "\s-\v\$ ".  In at least Bash 4.2 and 4.3 (but most likely also all prior versions) the PROMPT_COMMAND setting causes problems when editing command lines that exceed the width of the terminal: it causes the cursor to disappear or jump to the wrong positions.

I submitted a new Bash bug report for it today but it may also be discussed in Bug #2 in the report below:

http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00004.html

As noted in the remainder of the thread, there is little point in setting PROMPT_COMMAND to a command like printf since the same effect (but without the problems) can be achieved by setting the PS1 variable.  The purpose of PROMPT_COMMAND is to execute command just before displaying the prompt.  For example, the command could increment a number and store it in a Bash variable whose value could then be displayed in PS1, like so:

    PROMPT_COMMAND='n=$((++n))'; PS1='$n: '

Since the Bash bug is unlikely to be fixed, please change Mock to avoid setting PROMPT_COMMAND to a command that prints anything to stdout (or stderr). Instead, use the PS1 variable.

To reproduce the problem:

1) Open a terminal window (either XTerm or GNOME Terminal) 80 columns wide.
2) Either set the TERM variable to vt100 or xterm, or unset it.  The setting doesn't eliminate the problem but tends to have a slightly different effect on how it manifests.
3) Enter a Mock chroot, for example by invoking: mock --shell --unpriv.
4) Observe the shell prompt and the cursor after the trailing space.
5) If using GNOME Terminal, type as many characters as necessary for the cursor to advance to the last column of the terminal window. Then type one more character and observe the cursor disappear. (It doesn't seem to disappear in XTerm.)
6) In either terminal proceed to type more characters. The line will wrap around, continuing in column 1. Before the cursor advances to line up with the first typed character on the line above, observe it jump to column 1.
7) Continue typing more characters and observe the text overwrite the previously typed and displayed characters.
8) Enter ctrl+a to move the cursor to the beginning of the typed line and observe it jump into the middle of the prompt instead to the beginning of the typed text.

Comment 1 Martin Sebor 2015-04-27 19:26:54 UTC
See the following post for the bug report submitted to bug-bash:
http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00174.html

Comment 2 Fedora End Of Life 2015-11-04 12:29:39 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 '21'.

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 21 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.

Comment 3 Jan Kurik 2016-02-24 13:23:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 4 Pavel Raiskup 2016-04-21 06:27:29 UTC
Yes, please stop setting PROMPT_COMMAND, it is completely useless and it
just complicates working with shell history.  To me, it is 100% useless
feature at all so I would personally avoid setting PS1 to some non-default
value.

Comment 5 Pavel Raiskup 2016-04-21 06:30:49 UTC
Work-around is to set PROMPT_COMMAND variable to empty value in
/etc/mock/site-defaults.cfg.

Comment 6 Mikolaj Izdebski 2016-04-21 07:22:19 UTC
I can provide a patch to fix this if anyone is interested.

But I agree that PROMPT_COMMAND is bugged and useless. In my config I have it disabled for ages: config_opts['environment']['PROMPT_COMMAND'] = ':'

Comment 7 Miroslav Suchý 2016-04-21 07:51:45 UTC
Note: there has been recently commit 72f443b5c3ef5e2017868350adfcd4b6b5254657 which can be releavant to this BZ.

Comment 8 Fedora End Of Life 2017-07-25 18:54:23 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. 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 '24'.

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 24 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.

Comment 9 Fedora End Of Life 2017-08-08 11:57:17 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.


Note You need to log in before you can comment on or make changes to this bug.