Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
.`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].
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.
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 3Siteshwar Vashisht
2017-10-27 13:56:41 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
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
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 13Siteshwar 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 14Siteshwar Vashisht
2019-05-27 10:25:42 UTC
Can you review the doc text ?
Comment 16Siteshwar Vashisht
2019-05-27 12:57:23 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.