Re: Readline 8.3 regression: Prompt corruption with multibyte characters

On Mon, 6 Jul 2026 at 05:29, Chet Ramey <[email protected]> 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 =E2=
=80=9Cuser
error=E2=80=9D when they're likely not the author of the command in questio=
n.
This can especially be an issue when `stty ctlecho echo` is in effect, and
SIGINTR (`^C`) and/or SIGQUIT (`^\`) are caught and handled as "abort and
exit".

Such issues are not likely to get fixed any time soon, so I simply add this
in my .bashrc (after the point where PS1 is normally set):

    shopt -s checkwinsize
    printf -v _MissingEOL '%-*ls' $(( 1024 + COLUMNS * 4 )) '=E2=97=81=E2=
=97=81=E2=97=81 missing
newline'
    tput xenl ; _MissingXENL=3D$?

PS1=3D'\[\e[1;7;31m${_MissingEOL:0:COLUMNS-_MissingXENL}\r\e[m\e[2K\]'"$PS1=
"

This works in any(*3) ANSI-compatible terminal that supports the =E2=80=9Ca=
m=E2=80=9D
capability
(automatic line wrapping; *4), as long as the terminal width is sane. The =
=E2=80=9C
xenl=E2=80=9D capability (delayed line wrapping; *5) is common but not univ=
ersal.
Tune the colours and phrasing to your own preferences.

I've been using this for a while and it seems to work reasonably cleanly:
it avoids the synchronisation issues that can arise when trying to read the
cursor position from the terminal, but some terminals may reveal extraneous
warnings when their windows are shrunk.

Perhaps something equivalent to this could be provided as an option in
readline?
Or done separately, just before reporting process status changes?

If there's no appetite for adding this as a built-in feature, could we at
least have a hook before reporting status changes so we can do so ourselves=
?

-Martin

PS: Personally, I would prefer the default warning to include a clear
indication that the preceding command's behaviour was defective (rather
than just silently inserting a newline), and for the method of overriding
the text of this warning to be labelled with similar effect. (*6)

PPS: footnotes

(*1: and isn't empty)
(*2: even `git log --pretty=3Dformat:xxx` does this, but at least it offers
`git log --pretty=3Dtformat:xxx` instead; see `git man log`)
(*3: Change the warning text if your terminal or locale doesn't support
UTF-8; I just included the `=E2=97=81` symbols to show it's feasible.)
(*4: technically known as "automatic margin"; however I've *never* seen a
software terminal emulator that lacked this capability, so I don't even
bother to code a guard for it.)
(*5: technically known as "newline glitch"; don't wrap to the next line
until the /next/ output byte is received)
(*6: e.g. rename my example's `_MissingEOL` to
`BASH_DEFECTIVE_OUTPUT_WARNING`; and yes I know this would require
localisation, so "no warning" has to be distinguishable from "default
warning")