Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multibyte characters get corrupted when KEYBD trap is set #197

Open
siteshwar opened this issue Dec 7, 2017 · 2 comments
Open

Multibyte characters get corrupted when KEYBD trap is set #197

siteshwar opened this issue Dec 7, 2017 · 2 comments
Labels

Comments

@siteshwar
Copy link
Contributor

siteshwar commented Dec 7, 2017

Steps to reproduce:

  • Add KEYBD trap in /etc/kshrc (if it does not exist) :
# key bindings - make Delete, Home, End,... work
keybd_trap () {
  case ${.sh.edchar} in
    $'\e[1~') .sh.edchar=$'\001';; # Home = beginning-of-line
    $'\e[F')  .sh.edchar=$'\005';; # End = end-of-line
    $'\e[5~') .sh.edchar=$'\e>';; # PgUp = history-previous
    $'\e[6~') .sh.edchar=$'\e<';; # PgDn = history-next
    $'\e[3~') .sh.edchar=$'\004';; # Delete = delete-char
  esac
}
trap keybd_trap KEYBD
  • Add a test user and switch to it:
useradd test -s /bin/ksh
su - test
  • Type あいうえお from keyboard

Actual results:

BDFHJ is displayed.

Expected results:

あいうえお should be displayed.

There is some discussion around it in the abandoned patch #83

Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1503922

@siteshwar siteshwar added the bug label Dec 7, 2017
@k-takahagi
Copy link

Steps to reproduce:
rlogin localhost
Type あいうえお from keyboard
Actual results:
^A^Aいうえお is displayed.
Expected results:
あいうえお should be displayed.
Is this the same bug?

$ uname -s -v
SunOS 11.3
$

@siteshwar
Copy link
Contributor Author

@k-takahagi Do you have KEYBD trap set ? It should not reproduce when KEYBD trap is not set.

McDutchie added a commit to ksh93/ksh that referenced this issue Dec 30, 2024
The KEYBD trap should now be fully functional for UTF-8 and other
multibyte locales. Thanks to Johnothan King for finding this fix!

Analysis: The KEYBD trap code processes character code points
stored in e_lbuf by ed_read(). But shell variables store bytes, not
characters. So, in UTF-8 locales for example, the Unicode code
points need to be converted to multibyte UTF-8 encoding. This is
needed to calculate the length of each encoded character in bytes
(which fixes the corruption issue) and for keytrap() to store its
UTF-8 representation in ${.sh.edchar}.

src/cmd/ksh93/edit/edit.c: ed_getchar():
- Remove the workaround from the referenced commit.
- Use mbconv to convert innput codepoints to bytes before adding
  them to inbuff, a char array that is passed on to keytrap().

Related:  https://bugzilla.redhat.com/show_bug.cgi?id=1503922
Related:  att#197
Related:  #307
Resolves: #460
Co-authored-by: Johnothan King <[email protected]>
McDutchie added a commit to ksh93/ksh that referenced this issue Dec 30, 2024
The KEYBD trap should now be fully functional for UTF-8 and other
multibyte locales. Thanks to Johnothan King for finding this fix!

Analysis: The KEYBD trap code processes character code points
stored in e_lbuf by ed_read(). But shell variables store bytes, not
characters. So, in UTF-8 locales for example, the Unicode code
points need to be converted to multibyte UTF-8 encoding. This is
needed to calculate the length of each encoded character in bytes
(which fixes the corruption issue) and for keytrap() to store its
UTF-8 representation in ${.sh.edchar}.

src/cmd/ksh93/edit/edit.c: ed_getchar():
- Remove the workaround from the referenced commit.
- Use mbconv to convert innput codepoints to bytes before adding
  them to inbuff, a char array that is passed on to keytrap().

Related:  https://bugzilla.redhat.com/show_bug.cgi?id=1503922
Related:  att#197
Related:  #307
Resolves: #460
Co-authored-by: Johnothan King <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants