Command line editing off by one

[andreasf]

Sometimes editing the command line by arrow keys and backspace/delete leads to the edited result displayed correctly, but after hitting enter, e.g., bash complains about a slightly differing command line with a letter duplicated or the wrong one(s) deleted, always off by +/-1 characters. Issue is persistent when using the up key to edit the previous command.

Noticed in the default shell in-string as described above; in cpan, after backspacing one char too many, I get leading 'A' chars - could be a different issue though.

This is at hrev36382 but has been around some time.

In both apps simply retyping the command correctly works around the issue.

[jackburton]

Could be related to multi byte characters ?

[andreasf]

Possibly, but the commands themselves were ASCII only.

[andreasf]

Here's a reproducible test case with multi-byte character:

Type:

git config --global user.email "Andreas Färber"

After hitting enter, use the up key to get this line again and use the backspace key to remove everything after the dot. Make it read:

git config --global user.email myemail@example.org

and press enter. Instead of the above it will have executed:

git config --global user.nemail myemail@example.org

Verifiable by git config -l or by looking at /boot/home/.gitconfig file.

So it seems the backspace key removes one byte rather than one character.

[stippi]

I can confirm that this always happens after accidentally (or not...) entering a multi-byte character. Trying to remove that character leads to inconsitency between the display command line and the internal representation.

[andreasf]

Oops, typos in my test case:

s/user.email/user.name/g in the original command line, therefore the stray 'n' in user.nemail.

Optionally add --global for verifying, too.

[bonefish]

The Terminal is innocent here. Besides that it should properly deal with UTF-8, it also doesn't have any influence on the command line buffer the shell uses. This is a bash or readline issue. Actually I thought it had been fixed quite some time ago. But maybe this is a regression introduced with the update to bash 4.

[bonefish]

Replying to bonefish:

Actually I thought it had been fixed quite some time ago. But maybe this is a regression introduced with the update to bash 4.

Or I just dreamt it. At least in the bash commit log I couldn't find anything related. I could have sworn this was a wchar related problem, though.

[bonefish]

Closing as duplicate of #6276, which has the better description and summary.