Ow,
I'm sorry for not having investigated further, since I thought it was kind
of expected.
Thank you for doing it, Greg.
Hope this will be fixed.
Kind regards,
Enrico Maria
Il giorno mar 4 set 2018 alle ore 15:28 Greg Wooledge <wool...@eeg.ccf.org>
ha scritto:
> On Mon, Sep 03, 2018 at 01:13:03PM +0200, Enrico Maria De Angelis wrote:
> > The version number of bash: GNU bash, version 4.4.23(1)-release
> > The hardware and operating system: Arch LInux (constatly update)
> > The compiler used to compile: I didn't compile bash myself
> > A description of the bug behaviour: & A short script or `recipe' which
> > exercises the bug:
> > While vi-editing a line like the following
> > $ ls bulk32³ grids.dat COPYING
> > with the cursor in normal mode at the beginning of the line, hitting e
> > repeatedly, cause the cursor to move in order to
> > s of ls (correct)
> > 2 of bulk32³ (correct, since Vim itself works like this, with an end of
> > word being detected in between 2 and ³)
> > end of line (wrong)
>
> I can confirm this in Debian's bash 4.4.12 and in bash 5.0-alpha. It's
> actually worse than Enrico reports.
>
> First, the cursor doesn't actually move to the end-of-line character
> ('G'). The cursor moves one space *past* that.
>
> Once there, pressing either 'h' or 'b' moves the cursor from end-of-line
> back to the ³ character. That's fairly odd on its, own, but it gets
> even more interesting.
>
> If you go back to beginning-of-line, then press 'e' 3 times (so the cursor
> is beyond the 'G'), then press 'i' ' ' to insert a space character, the
> multi-byte character gets broken up. What I see is this:
>
> wooledg:~$ ls bulk32� � grids.dat COPYING
>
> So, it seems the space was inserted in the middle of the byte sequence
> that constituted the ³ character (0xc2 0xb3) originally, resulting in
> two invalid-character bytes with a space in the middle.
>
> This is in LANG=en_US.UTF-8 on Debian 9 amd64.
>
