Description of problem: If an application whose name or path includes multibyte characters is executed on ja_JP.UTF-8 locale, ps(1) cannot output the application name correctly. Version-Release number of selected component (if applicable): 2.0.13-9.2E How reproducible: ã»always Steps to Reproduce: 1. $ echo $LANG 2. $ ./ãã¹ã 3. $ ps -al Actual results: $ echo $LANG ja_JP.UTF-8 $ ./ãã¹ã & [1] 18904 $ ps -af UID PID PPID C STIME TTY TIME CMD . . root 18795 1 0 12:38 tty1 00:00:00 /usr/libexec/gconfd-2 5 root 18904 18876 0 15:59 pts/5 00:00:00 ./????? root 19148 2893 0 15:59 pts/0 00:00:00 ps -af $ Expected results: ps(1) output application name correctly $ ./ãã¹ã & [1] 18904 $ ps -af UID PID PPID C STIME TTY TIME CMD . . root 18795 1 0 12:38 tty1 00:00:00 /usr/libexec/gconfd-2 5 root 18904 18876 0 15:59 pts/5 00:00:00 ./ãã¹ã root 19148 2893 0 15:59 pts/0 00:00:00 ps -af $ Additional info:
Mass reassign to new owner
Could you try this with procps 3.1.15
Comments from Upstream Maintainer. Fixing this is somewhat dangerous. Process names are untrusted data. If they contain escape codes, they could reprogram the terminal's keys! The byte (0x80|'\e') must NEVER be printed. If the terminal is not really in UTF-8 mode, all sorts of mayhem can occur. Beyond that... sure, something could be done. Troublesome characters should be filtered out. These include: * major UTF-8 encoding violations (0x88 0x88 0x88 0x88) * minor UTF-8 encoding violations (non-canonical form) * anything else likely to confuse a terminal
The problem with UTF-8 cannot be fixed in RHEL3 / RHEL4. It require rewrite a lot of code in "ps". This is done in version 3.2.4 that is avaiable for FC4 and probably will in new RHEL (>4) versions.