RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 2022-01-04 13:17 UTC (History)
8 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:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github att ast issues 197 0 'None' open Multibyte characters get corrupted when KEYBD trap is set 2021-02-12 14:16:44 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
Comment 18 Kamil Dudka 2022-01-04 13:17:50 UTC 
This bug is now being revisited by ksh upstream: https://github.com/ksh93/ksh/issues/307
Note You need to log in before you can comment on or make changes to this bug.