Description of problem: ps(1) cannot output a process name or a path including mulitibyte characters. Version-Release number of selected component (if applicable): procps-3.2.3-3 How reproducible: always Steps to Reproduce: 1. Specify Japanese character 'ã¦ãã¨' as an application name. # cc test.c -o ã¦ã㨠2. # ./ã¦ã㨠& 3. # ps -a ----- // test.c main(){ sleep(60); } ----- Actual results: # ps PID TTY TIME CMD 3286 pts/3 00:00:00 bash 3412 pts/3 00:00:00 ?? 3413 pts/3 00:00:00 ps Expected results: [root@plat-tiger4b tmp]# ps PID TTY TIME CMD 3286 pts/3 00:00:00 bash 3412 pts/3 00:00:00 ã¦ã㨠3413 pts/3 00:00:00 ps Additional info:
*** Bug 134780 has been marked as a duplicate of this bug. ***
There's a corresponding RHEL3 bug as well as #112518.
Created attachment 104887 [details] procps-3.2.3 utf8 patch for your tests..
Thank you so much. It works well. Will this patch be applyed soon? Regards,
This patch is not right :-) I have new and better version and I just test it together with upstream maintainer.
Created attachment 105113 [details] v2 of UTF8 procps patch
Thanks for the revised patch. ps(1) can output UTF8 multibyte characters. But some commands such as w(1), pmap(1) and top(1) abnormally end with segmentation fault.
Sorry. It's already fixed in latest patch version. I forgot release at bugzilla. The patch will available in next procps upstream and RH release -- now I need one or two days for tests. Thanks for your interest.
The beta version with UTF8 support: http://people.redhat.com/kzak/procps/beta/
The UTF-8 support for "ps" is done in new version (3.2.4) of procps, but this version is not included in RHEL4 (we will see it probably in next enterprice version). The stable patch is available now when RHEL4 is in the beta state and it's too late. The first distribution with this feature will FC4.