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.
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
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.
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.
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.
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".
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.
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?
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.