Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Enrico Maria De Angelis <enricomaria.dean6elis@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Bash vi mode's e command (end of word) goes to eol when hitting a unicode character
Date: Tue, 4 Sep 2018 19:54:15 +0200
Lines: 51
Approved: bug-bash@gnu.org
Message-ID: <mailman.367.1536083671.1284.bug-bash@gnu.org>
References: <CAO_nHy=zert9rccYGQQOAcYmi5V=bq6eTgtx+AeANFoS_-HDww@mail.gmail.com> <20180904132833.4f5oo4qjefwzyvyw@eeg.ccf.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
In-Reply-To: <20180904132833.4f5oo4qjefwzyvyw@eeg.ccf.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:14549

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 <wooledg@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=C2=B3 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=C2=B3 (correct, since Vim itself works like this, with an e=
nd of
> > word being detected in between 2 and =C2=B3)
> > 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 =C2=B3 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 curso=
r
> 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=EF=BF=BD =EF=BF=BD grids.dat COPYING
>
> So, it seems the space was inserted in the middle of the byte sequence
> that constituted the =C2=B3 character (0xc2 0xb3) originally, resulting i=
n
> two invalid-character bytes with a space in the middle.
>
> This is in LANG=3Den_US.UTF-8 on Debian 9 amd64.
>