Control: retitle -1 ksh: parsing of floating-point constants is broken in locales where the decimal point is not "."
On 2018-04-06 12:45:33 +0300, Andrey ``Bass'' Shcheglov wrote: > The issue is actually locale-dependent: > > ksh infers the decimal separator from LC_NUMERIC, and since my locale is > ru_RU.UTF-8, > it expects a comma (,) instead of a dot (.). > > Strange thing is, LC_NUMERIC affects neither zsh nor bc -- only ksh. > > I believe this behaviour should be at least documented somewhere. There is documentation, but it does not match the observed behavior. The man page says under "Arithmetic Evaluation.": "Floating point constants follow the ANSI-C programming language floating point conventions." In C, like in many programming languages, the locales do not influence the syntax of literals, e.g. "1." is the floating-point constant 1 whatever the locale. However, in CAVEATS, it says: "It is a good idea to leave a space after the comma operator in arithmetic expressions to prevent the comma from being interpreted as the decimal point character in certain locales." but that's no the main documentation. I'd rather say that this is a bug in the code (otherwise, hardcoded constants in scripts would be an issue, in particular), which blindly use standard library functions in the current locale. This would also solve the current inconsistency with Turkish locales: cventin:~> LC_ALL=tr_TR.utf8 ksh $ echo $((Inf)) inf $ echo $((ınf)) 0 while the lowercase form of "Inf" is "ınf", not "inf", i.e. ksh does not seem to honor the current locale for infinity. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
