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.

Regards,
Jaromir.

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
 4.2
 $ 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.

http://rhn.redhat.com/errata/RHBA-2014-1595.html