Bug 1105125 - Locale dependent float delay in top and watch utilities
Summary: Locale dependent float delay in top and watch utilities
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: procps
Version: 6.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jaromír Cápík
QA Contact: Martin Frodl
Depends On:
TreeView+ depends on / blocked
Reported: 2014-06-05 12:52 UTC by Pavel Roschin
Modified: 2016-02-01 02:00 UTC (History)
3 users (show)

Fixed In Version: procps-3.2.8-28.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1182248 (view as bug list)
Last Closed: 2014-10-14 08:22:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1595 0 normal SHIPPED_LIVE procps bug fix and enhancement update 2014-10-14 01:39:48 UTC

Description Pavel Roschin 2014-06-05 12:52:28 UTC
Description of problem:

Different behavior in watch and top utilities while decimal point delimiter != ".". Depending on package (procps, procps-np) those utilities implement locale settings in different way.

Version-Release number of selected component (if applicable):
All RHEL from 6.0 to 6.5, possibly earlier versions, also Fedora and RHEL implementations of top utility look different while LANG=ru_RU.UTF-8.

How reproducible:

Depends on current/environment locale.

Steps to Reproduce:

Just try those under different locales. Other utilities that accept float arguments are possibly affected.

1. LANG=C top -d0.5 - OK
2. LANG=C watch -n0.5 date - OK
3. LANG=ru_RU.UTF-8 top -d0.5 - OK
4. LANG=ru_RU.UTF-8 top -d0,5 - FAILED (dealy is set to 0, no error reported)
5. LANG=ru_RU.UTF-8 watch -n0.5 date - FAILED (shows usage)
6. LANG=ru_RU.UTF-8 watch -n0,5 date - OK

Actual results:

There is no locale conventions in software from one package. In Fedora (tested 20) top follows locale but it not only accepts locale-dependent delay but also shows locale-dependent floating-point numbers that differs from RHEL.

Expected results:

Possible expected results.
1. All software should work with locale as expected in the same way (in C locale "0.5" values are OK, in ru_RU locale "0,5" values are OK). From this point of view top and watch utilities in Fedora work correctly. Report about incorrect values.
2. Accept both variants for compatibility reasons. I didn't see that manuals for top or watch pointed about locale dependent arguments, but maybe there is some agreement.

Comment 3 Jaromír Cápík 2014-06-18 17:57:07 UTC
Hello Pavel.

The Fedora component uses locale honoring functions. The idea of fallback to the second variant sounds good in general, I'm just unsure whether this is what everyone wants. Some custom scripts could use this flaw (for example using ',' as separators). But, even changing the 'top' behaviour from accepting '.' to ',' could be unwanted and cause regressions. So, it's difficult for me to decide.


Comment 4 Pavel Roschin 2014-06-19 12:43:01 UTC
The main idea is to make Fedora/RHEL compatible while accepting _arguments_. In Russian locale float numbers like "0,1" are correct but as user I always enter "0.1" while passing command line arguments - many software accept only that form of floating numbers.

Example (ru_RU locale):
 $ echo "2+2.2" | bc -l
 $ echo "2+2,2" | bc -l
 (standard_in) 1: syntax error

But bc at least report about error while top doesn't and 'top -d0,5' works like 'top -d0'.

This is very common mistake especially in configuration files (config written with en_US locale cannot be accepted in ru_RU locale because fscanf/atod expects for commas). I hate this libc "handy" feature.

Output is much harder. Sure some scrips may parse e.g. 'top -b -n1' output and printing commas instead dots will cause unexpected bugs depending on user's locale settings. Actually Fedora already had broken compatibility with RHEL by printing commas instead dots (RHEL doesn't do that).

It would be nice to accept both (comma and dot) in command line arguments and keep output "as is".

Comment 5 Jaromír Cápík 2014-06-24 15:27:03 UTC
Ok ... I did the proposed change even when not accepted by the rest of the procps-ng upstream members yet. Hopefully I'll be able to convince the guys this is what we want upstream. And breaking custom scripts misusing the flaw is acceptable risk in this case.

Comment 8 Martin Frodl 2014-07-08 09:00:14 UTC
One more thing I would like to ask. On RHEL 7, decimal point in ru_RU.utf8 locale is treated the same way decimal commas are treated in e.g. en_US.utf8 locale. That is, 

$ LANG=ru_RU.utf8 watch -n0.5 date
watch: failed to parse argument: '0.5'
$ LANG=ru_RU.utf8 top -d 0.5
[top executes with refresh interval apparently set to 0]

This is definitely a correct solution, but alas, incompatible with the RHEL 6 approach (accept decimal points AND commas). So, would it be reasonable to report this incompatibility as a new bug, or is this going to become a feature from now on?

Comment 9 errata-xmlrpc 2014-10-14 08:22:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.