Date: Sat, 26 Jan 2019 12:28:08 +0100
From: Kamil Rytarowski <n...@gmx.com>
Message-ID: <d76ee9ad-71e5-a087-d31b-00c205285...@gmx.com>
| This is where I disagree. In my opinion (of a native user of ",") -
| parsing locale specific input for such programs doesn't make sense.
I don't want to argue, as, as has been pointed out, I don't actively
use locales much, but this confuses me.
If you don't want to (normally) use locales at all, I'd expect you'd
just pretend to be me, and not set any of the LC variables at all,
except when you are going to run one of those special programs
which you want generate locale specific values. Or perhaps
more likely, you might have LC_CTYPE set so your language
char set can be recognised, but none of the others.
Then all the normal programs like sort will act the way that you
want them too, no LC_NUMERIC so to sort floats they need to
be written with a '.', no LC_COLLATE so you get ascii ordering
(as I understand it, on NetBSD that's what you get anyway...)
Or you can do it the way you seem to be suggesting and have
all the programs (but a few) ignore locales (except LC_CTYPE?)
completely, so you can set the LC_ vars to whatever you like
and they will change nothing. That seems a bit odd to me.
Then, what do you do, when someone sends you a file full of
columns of floating numbers (intermixed with integers, ie: when the
fraction would be 0 it jas just been omitted, along with the radix)
that are in the common European format, which also contains periods
in other places, including perhaps near the numbers and need to
sort it, and then send it nack. WIth the first method, you'd just do
something like:
LC_NUMERIC=pl sort [options] file
but if sort is ignoring LC_NUMERIC, that won't work, and I suspect
that you'd need to cojvert the file from ',' floats to '.' floats, sort,
and then convert back - an error prone and annoying operation
(not impossible to do, but not always easy either - certainly not
as simple as tr , . followed by tr . , as that would convert chars
that used to be '.' (like after someone's initials, in a name) into
'.' incorrectly. It all gets ugly, and typically takes special case
code for every different example you're faced with.
That doesn't seem appealing to me, and I think I'd like it if all
I had to do to deal with such a file was temporarily set an env
var and it would all just work, even if I didn't believe that format
file should ever exist.
Note, this is not about whether people ought to be using ',' as
the radix or not, whether that's gradually vanishing, ... That
is a whole other question, and one where I probably agree with
you - the more meaningless differences there are in different
regions (which side of the road to drive on, how to write floating
numbers, metric or imperial, 24 or 12 hour clocks, ...) for which
there is no particularly good reason for most (well, metric is clearly
better than imperial, and 24 hour clocks are the way to go as
well ... IMO anyway) the world would be simpler, more efficient,
and generally better if all those differences could just magically
go away. Some probably will, in time, others not., but that's out
of scope for us, we cannot make any of that happen here.
While the differences exist, we need to find ways to work with
them, not simply wish them away and pretend they don't exist.
That never works.
kre
