On 26.01.2019 02:30, Robert Elz wrote: > Date: Fri, 25 Jan 2019 15:51:05 +0100 > From: Kamil Rytarowski <n54%gmx.com@localhost> > Message-ID: <e1ba49e4-f6ce-4f56-57ad-0508464602cd%gmx.com@localhost> > > | sort(1) > | stat(1) > > Those take no floating point input that I can see. For sort, > its only use of floats would be sorting files containing them, > for which (I assume) one would want and expect the file > to be a locale specific format, and for sort to recognise > the floats in a locale specific way. This is where I disagree. In my opinion (of a native user of ",") - parsing locale specific input for such programs doesn't make sense. Locale specific format is in my opinion appropriate only for programs that process text for printing (like man(1) or groff(1)). > Whether our sort does > that or not I have not tested (I have no files with floating > numbers in them, and if I did, they'd use '.' ...) > > | bc(1) > | dc(1) > > Those have their own purpose built language with > a tightly specified grammar. They even consider > A B C ... as numbers, not as letters. They are > useless as a point of consideration. > > | timeout(1) > > That uses strtod() to parse the floating point command > line args, so is locale specific, but just like FreeBSD's > sleep, does not call setlocale() so runs only in the C > (aka POSIX) locale, and so does not adapt in any > way to the user's locale settings (including any output > it might generate in the case of an error - no locale > specific strerror() strings.) > > | printf(1) > > This one perhaps. But again, what it accepts is very > precisely specified (that we had not noticed that we did > not implement that was, I think, an oversight, which will > be fixed). > > kre >
Attachment:
signature.asc
Description: OpenPGP digital signature