Date: Sun, 27 Jan 2019 22:56:17 +0100 From: Kamil Rytarowski <n...@gmx.com> Message-ID: <1906f04e-93b9-a2c5-62a0-bf430ca60...@gmx.com>
| Passing to sleep 1,2 or 1.000 makes as much sense The question isn't really whether it makes sense, that's up to the user to decide, not us, but whether it could be interpreted any other way. The first of those has "worked" on NetBSD ever since support for fractional seconds got added (whaver the locale) until very recently - where "worked" is in quotes as the sleep might have lasted for one second, or one and one fifth seconds, or as close to that as the system can manage, but there would have been a 1 second (approx) sleep in any case). The second case is ambiguous, which is (I presume) why no-one is expecting that to ever mean anything except a very precise 1, and why the grouping chars are never supported for input., whatever they are, and only works to the extent that the extra input precision is completely ignored, and does not cause sleep to attempt to really only last exacly 1 second, rather than perhaps 1 second and 5 milliseconds, which "sleep 1" might delay for (or even longer.) A better question than "does it make sense" is "what else could it reasonably mean", and if there is no other answer than "nothing" (which is true for the first of those, but not the second) then when there is no other meaning that makes sense, ask "is there any plausible potential use for this?" and if the answer to that is yes, then why not support it? Incidentally, the better input to have asked about would have been 0,2 as until recently, that one did not "work" in any sense unless the locale uses ',' as the radix char (and that has not changed) or 0.2 (the kind of example that caused this discussion) when the radix char is ',' (or something other than '.'). No-one here is disputing that the 0.2 case should always work, and not be an error. That is what was fixed. The only question is whether there is any harm in also accepting the 0,2 form when ',' is the "decimal point". | as passing to it 1000USD. Until PR 53910 was pre-emptively fixed recenty, that one would also have "worked" (though the perhaps slightly more common in many areas, USD1000, would not) . That PR needed to be fixed, even before it was filed, as stray characters after the numeric value are more likely to be something attempting linux "sleep 2m" (ie: sleep 120) raher than someone attempting to sleep for a currency value. And that does need to be detected as an error, unlike "sleep 1,2" (or even sleep 0,2) which does no real harm, even if it was an accident (we're talking about a sleep of some extra fraction of a second...) kre ps: Another command affected by all of this is "seq" which also takes floating point command line args. That is not in posix, so we get no guidance there. This one is a very odd case, the first three executable lines in it are ... /* Determine the locale's decimal point. */ locale = localeconv(); if (locale && locale->decimal_point && locale->decimal_point[0] != '\0') decimal_point = locale->decimal_point; and then it does everything (validating input, ...) based upon that "decimal_point" variable, to the extent of (properly it seems to me from just reading the code) dealing with the possibility that the "decimal_point" might be a multiple byte string (ie: not '.' or ',' but perhaps something with a 2 byte or longer UTF-8 encoding, or something). That is, it uses "strstr()" to locate the radix. That is, it is very clearly and very explicitly written to accept, and generate, input and output in the user's locale. Except ... Note the "first three executable lines" and consider the implication of that .... there is no setlocale() call, which means the program is required to run in the C locale ignoring LC_* environment vars, and therefore, "locale" there is always the C locale, and consequently decimal_point is always "." and all of the (considerable) work that the code goes to to be able to operate in different locales is wasted. seq seems to have mostly come from Plan-9 where the requirement for setlocale() presumably (I have never run it, or even seen it running) does not exist, and locales are simply always used if set. I do not plan on "fixing" this any time soon (the FreeBSD version was taken from ours, and has the same issue, exactly, OpenBSD do not have seq at all, and linux, which had it before us, have, I think, just - within the past couple of days - made it (and sleep) handle both the C locale, and the user's locale, interchangably. But if we do decide to leave sleep as it is now, then it will make sense to fix seq to have the same flexibility, but that one is not going to be a trivial change - as it is written now, it really only wants to operate in a single locate (whatever it is) and not in the user's locale, or the C locale, whichever works better... Perhaps for that one, a better fix than just accepting numbers in either locale, and generating the sequence in the user's locale (which is what might happen) would be to intuit the locale (when floats are used, which is all that matters in this case) from the input, so if the floating input works for the user's locale, use that, for both input and output, and if not, switch completely to the C locale, and use that for both input and output. That way "seq 0.3 0.1 0.8" would work, and generate a C locale sequence of numbers, and in an appropriate locale "seq 0,3 0,1 0,8" would work, and generate a sequence of numbers appropriate to that locale, and in all cases "sed 0,3 0.1 0.8" (and similar) would be an error. Doing that would probably be easier (less intrusive) for seq than simply allowing it to accept numbers in either locale, while generating them in the user's locale. We also have to decide what to do with printf... Linux is (also recently I believe) accepting numbers in either locale, and generating them in the user's locale. Our /usr/bin/printf takes numbers in the user's locale and generates them that way. The printf built into /bin/sh (and csh I think) only allows the C locale, as (because of current sh limitations) built-ins are not permitted to change the locale. That will eventually get fixed in sh (it has been already in FreeBSD.)