bin/54152: sh line-editor updating weirdness

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>Number:         54152
>Category:       bin
>Synopsis:       sh input line editor mis-updates
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 02 17:10:00 +0000 2019
>Originator:     Mouse
>Release:        NetBSD 8.0
>Organization:
	Dis-
>Environment:
System: NetBSD Aaeon.Rodents-Montreal.ORG 8.0 NetBSD 8.0 (MAQ) #1: Wed May  1 17:05:41 EDT 2019
Architecture: amd64
Machine: amd64
>Description:
	sh(1)'s input line editor mis-updates the line under
	circumstances whose details are unclear to me.
>How-To-Repeat:
	Here's how I did it.  I don't know how much of this is
	necessary; I haven't probed the envelope of the bug to any
	significant extent.

	Log in to a stock 8.0 system from an 80x24 window, to an
	account set up to use sh with the stock prompt ("$ ").

	Set terminal type to mterm.  (If not actually using mterm, of
	course, the display won't be as described, but inspecting the
	generated output by doing the whole thing under script(1)
	reveals the syndrome described below.)

	In my case, the previous two steps were done with ssh from
	another system where the terminal type was already set to
	mterm.  I don't know whether it would work to log in with a
	different type and then set it to mterm after logging in.

	set -o emacs

	RETURN enough times for the cursor to be on the bottom line.

	Paste in
	(cd / && /home/mouse/mtar cf - usr/X11R7/lib/libXdmcp.so.7.) | (cd /sandbox && /home/mouse/mtar xvf -)

	The display correctly shows
	$ (cd / && /home/mouse/mtar cf - usr/X11R7/lib/libXdmcp.so.7.) | (cd /sandbox &&
	 /home/mouse/mtar xvf -)

	Type ^B enough times to place the cursor on the first ), ie,
	right after the ".7.".  (This appears to be noncritical; ^A and
	a bunch of ^Fs has also worked for me.)

	Now type 0.  The result:
	$ (cd / && /home/mouse/mtar cf - usr/X11R7/lib/libXdmcp.so.7.0) | (cd /sandbox &
	& 
	losing everything after the "&& ".

	This appears to be purely a display glitch; the missing text
	reappears upon typing ^E, and I feel reasonably sure it would
	be treated as present upon typing RETURN.

	The output generated in response to the 0 consists of

	- A carriage return (^M)
	- The text of the displayed line up to the point where the
	   cursor is (ie, "$ (cd....so.7.")
	- Enter insert mode (^Q)
	- 0
	- Exit insert mode (^O)
	- The remaining text on the first line (") | (cd /sandbox &")
	   (including wrapping to the beginning of the next line).
	- Clear to end of line (^C)
	- Enter insert mode (^Q)
	- &
	- Exit insert mode (^O)
	- One space
	- Cursor-up (^X)
	- The appropriate text to get back to where the cursor should
	   be (ie, "(cd /...so.7.0")

	That clear-to-end-of-line appears to be the problem, or perhaps
	the lack of repainting the text after it is.  (The CR and
	repaint of the line-so-far is grossly inefficient, but not
	otherwise wrong.  The clear-to-end-of-line and lack of
	subsequent repaint of that text, though, is outright wrong.)
>Fix:
	Unknown.  I haven't even been able to come up with a plausible
	theory of what's behind it (but I also haven't looked at sh's
	input line editor code at all).  Deleting and retyping the
	whole usr/.../7.0 string shows working updating of wrapped
	text, even including spaces, often enough that it's not just a
	question of VT100-style delayed wrap versus mterm-style
	immediate wrap, which was the only theory I had.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B