Opened 9 years ago

Closed 9 years ago

#5775 closed bug (duplicate)

Command line editing off by one

Reported by: andreasf Owned by: nobody
Priority: normal Milestone: R1
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc: siarzhuk
Blocked By: #6276 Blocking:
Has a Patch: no Platform: x86

Description

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.

Change History (9)

comment:1 by jackburton, 9 years ago

Could be related to multi byte characters ?

in reply to:  1 comment:2 by andreasf, 9 years ago

Possibly, but the commands themselves were ASCII only.

in reply to:  1 ; comment:3 by andreasf, 9 years ago

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.

comment:4 by stippi, 9 years ago

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.

in reply to:  3 comment:5 by andreasf, 9 years ago

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.

comment:6 by bonefish, 9 years ago

Component: Applications/TerminalApplications/Command Line Tools
Owner: changed from jackburton to nobody

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.

in reply to:  6 comment:7 by bonefish, 9 years ago

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.

comment:8 by siarzhuk, 9 years ago

Cc: siarzhuk added

comment:9 by bonefish, 9 years ago

Blocked By: 6276 added
Resolution: duplicate
Status: newclosed

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

Note: See TracTickets for help on using tickets.