Bug 1503922 - ksh display Japanese character wrong when 'KEYBD trap' is enabled
Summary: ksh display Japanese character wrong when 'KEYBD trap' is enabled
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ksh
Version: 7.4
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Siteshwar Vashisht
QA Contact: BaseOS QE - Apps
Lenka Špačková
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-19 05:21 UTC by ddu
Modified: 2019-07-03 12:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.`ksh` with the `KEYBD` trap mishandles multibyte characters The Korn Shell (KSH) is unable to correctly handle multibyte characters when the `KEYBD` trap is enabled. Consequently, when the user enters, for example, Japanese characters, `ksh` displays an incorrect string. To work around this problem, disable the `KEYBD` trap in the `/etc/kshrc` file by commenting out the following line: ---- trap keybd_trap KEYBD ---- For more details, see a related link:https://access.redhat.com/solutions/3219671[Knowledgebase solution].
Clone Of:
Environment:
Last Closed: 2019-07-03 12:04:39 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github att ast issues 197 'None' 'open' 'Multibyte characters get corrupted when KEYBD trap is set' 2019-11-26 14:38:57 UTC

Description ddu 2017-10-19 05:21:47 UTC
Description of problem:

In RHEL, when create a user and set it's shell to '/bin/ksh', it can not display Japanese character correctly.For example, "BDFHJ" will be displayed when type "あいうえお".

$ BDFHJ 

Version-Release number of selected component (if applicable):

ksh-20120801-34.el7

How reproducible:

Everytime.

Steps to Reproduce:

1. create a new user with setting it's shell to ksh.
# useradd test -s /bin/ksh

2. switch to test
# su - test

3. type 'あいうえお' from keyboard
$ あいうえお -> Press 'Enter' key
$ BDFHJ

4. copy 'あいうえお' and paste to the terminal
$ BDFHJ

Actual results:

"BDFHJ" is displayed.

Expected results:

"あいうえお" is displayed.

Additional info:

From /etc/kshrc, trap KEYBD is enabled by default.

~~~
# 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
~~~

When comment out 'trap keydb_trap KEYBD' line from /etc/kshrc, the Japanese character can be displayed normally.

Comment 2 ddu 2017-10-19 05:38:18 UTC
This problem will happen if 'KEYBD trap' is enabled, no matter what key bindings are set. It will happen even if following trap is set.

keybd_trap1 () {
    true
}
trap keybd_trap1 KEYBD

Comment 3 Siteshwar Vashisht 2017-10-27 13:56:41 UTC
https://github.com/att/ast/pull/83

Comment 4 Red Hat Bugzilla Rules Engine 2018-03-13 08:51:51 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 9 Siteshwar Vashisht 2019-04-25 10:24:53 UTC
Also, I have made this request on several other bugs and I am repeating it again. We are working to revive AT&T KornShell[1] and recently we made an alpha release[2]. I would like RHEL customers to try it out and provide us feedback. Packages for latest release can be found here[3] or you can subscribe to our copr repos[4] for latest development packages.

[1] https://github.com/att/ast
[2] https://groups.google.com/d/msg/korn-shell/7VAqQg1N5D8/XniWn__RBgAJ
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=34360564
[4] https://copr.fedorainfracloud.org/coprs/g/ksh/latest/

Comment 10 Keigo Noha 2019-05-07 00:51:47 UTC
Hi Siteshwar,

Thank you for your comment. Now I'm back from 10-days public holidays in Japan due to the change of Japanese Era.
I can test the new package in my environment. However, we, support team, cannot ask our customers to test EPEL package in their environment.
If you want the test result with the new package in Fedora, I'll report it to you.
If it doesn't help, please let me know and we need to discuss what is the better way to move this bugizlla forward.

Best Regards,
Keigo Noha

Comment 11 Keigo Noha 2019-05-07 08:07:38 UTC
Hi Siteshwar,

I tested with the test package in copr repos.
ksh-2020.0.0+git.77.g55599523-0.el7.x86_64 doesn't resolve the issue yet. User input, 'あいうえお' is still shown as 'BDFHJ'.
If I need to do more tests, please tell me the details. I'll do it in my lab.

Kind Regards,
Keigo Noha

Comment 12 Keigo Noha 2019-05-16 03:02:18 UTC
Hi Siteshwar,

Sorry for rushing you. Do you have anything which I can do for you on this bugzilla?
If you want me to do some test in my environment, please let me know.
If you have a chance, please share the current status in your side about this bugzilla.

Best Regards,
Keigo Noha

Comment 13 Siteshwar Vashisht 2019-05-16 04:10:54 UTC
> If you have a chance, please share the current status in your side about this bugzilla.

As mentioned in comment#8, fixing this bug carries risk of regression, so I am going to close this as wontfix.

Comment 14 Siteshwar Vashisht 2019-05-27 10:25:42 UTC
Can you review the doc text ?

Comment 16 Siteshwar Vashisht 2019-05-27 12:57:23 UTC
LGTM


Note You need to log in before you can comment on or make changes to this bug.