7ef38420a4
When this project first began implementing translation support nearly 6 years ago, we overcame many 'gettext' obstacles and limitations. And, of course, there were not any actual translations at the time so our testing was quite limited plus, in many cases, only simulated. None of that, however, can justify or excuse the total lack of attention to top's approach to NLS, especially since some actual translations have existed for years. When the issue referenced below was raised, I suffered immediate feelings of anxiety, doubt and pending doom. This was mostly because top strives to avoid line wrap at all costs and that did not bode well for multi-byte translated strings, using several bytes per character. I was also concerned over possible performance impact, assuming it was even possible to properly handle utf8. But, after wrestling with the problem for several days those initial feelings have now been replaced by guilt over any trouble I initially caused those translators. One can only imagine how frustrating it must have been after the translation effort to then see top display a misaligned column header and fields management page or truncated screens like those of help or color mapping. ------------------------------------------------------ Ok, with that off my chest let's review these changes, now that top properly handles UTF8 multi-byte strings. . Performance - virtually all of this newly added cost for multi-byte support is incurred during interactions with the user. So, performance is not really an issue. The one occasion when performance is impacted is found during 'summary_show()' processing, due to an addition of one new call to 'utf8_delta()' in 'show_special()'. . Extra Wide Characters - I have not yet and may never figure out a way to support languages like zh_CN where the characters can be wider than most other languages. . Translated User Name - at some future point we could implement translation of user names. But as the author of the issue acknowledged such names are non-standard. Thus task display still incurs no new multi-byte costs beyond those already incurred in that escape.c module. For raising the issue I extend my sincerest thanks to: Göran Uddeborg Reference(s): https://gitlab.com/procps-ng/procps/issues/68 Signed-off-by: Jim Warner <james.warner@comcast.net>
procps
procps is a set of command line and full-screen utilities that provide information out of the pseudo-filesystem most commonly located at /proc. This filesystem provides a simple interface to the kernel data structures. The programs of procps generally concentrate on the structures that describe the processess running on the system.
The following programs are found in procps:
- free - Report the amount of free and used memory in the system
- kill - Send a signal to a process based on PID
- pgrep - List processes based on name or other attributes
- pkill - Send a signal to a process based on name or other attributes
- pmap - Report memory map of a process
- ps - Report information of processes
- pwdx - Report current directory of a process
- skill - Obsolete version of pgrep/pkill
- slabtop - Display kernel slab cache information in real time
- snice - Renice a process
- sysctl - Read or Write kernel parameters at run-time
- tload - Graphical representation of system load average
- top - Dynamic real-time view of running processes
- uptime - Display how long the system has been running
- vmstat - Report virtual memory statistics
- w - Report logged in users and what they are doing
- watch - Execute a program periodically, showing output fullscreen
Reporting Bugs
There are a few ways of reporting bugs or feature requests:
- Your distributions bug reporter. If you are using a distribution your first port of call is their bug tracker. This is because each distribution has their own patches and way of dealing with bugs. Also bug reporting often does not need any subscription to websites.
- GitLab Issues - To the left of this page is the issue tracker. You can report bugs here.
- Email list - We have an email list (see below) where you can report bugs. The problem with this method is bug reports often get lost and cannot be tracked. This is especially a big problem when its something that will take time to resolve.
If you need to report bugs, there is more details on the Bug Reporting page.
Email List
The email list for the developers and users of procps is found at http://www.freelists.org/archive/procps/ This email list discusses the development of procps and is used by distributions to also forward or discuss bugs.