Re: Readline 8.3 regression: Prompt corruption with multibyte characters

On 7/7/26 11:59 PM, Martin D Kealey wrote:

>     Readline could force this, by printing a \r to make sure the cursor is in
>     column 0, but then you'd get complaints about overwriting the line
>     contents.
> 
> 
> The issue of prompts being disrupted when the preceding command's output 
> fails to end with a newline (*1) has come up numerous times.
> Much as I hate the recent prevalence of commands that produce 
> such defective output(*2), I don't think it's fair to give up and say “user 
> error” when they're likely not the author of the command in question.

No one is saying it's "user error." The issue is that one of readline's
basic assumptions is being violated. You can either hit newline when
something like this happens, or get fancier (completely untested):

_fetch_cursor_position()
{
	local -a pos
	IFS='[;' read -p $'\e[6n' -d R -a pos -rs || {
		echo "${FUNCNAME}: failed: $? ; ${pos[*]}" >&2
		return 1
	}
	_cursor_row="${pos[1]}"
	_cursor_col="${pos[2]}"
}

_prompt_command()
{
	_fetch_cursor_position && (( $_cursor_col > 1 )) && printf '\n'
}

PROMPT_COMMAND=_prompt_command

It all depends on how important it is to you, how often this happens, and
how much time you want to spend putting in an acceptable solution.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/