5:05 p.m.
Apparently ping has now started interpreting its command line arguments
depending on locale. I.e. ping -i 0.1 no longer works in locales where
comma is the decimal separator.
This makes it difficult to call system commands. The only workaround is
to set LC_ALL to a known-good locale, but then your users get no benefit
from the translations of error messages and so on.
Is Linux really doomed to repeat the mistakes made by Visual Basic more
than a decade ago?
/Benny
2:57 a.m.
On 2013-01-30, Benny Amorsen <benny+usenet(a)amorsen.dk> wrote:
Apparently ping has now started interpreting its command line
arguments
depending on locale. I.e. ping -i 0.1 no longer works in locales where
comma is the decimal separator.
This makes it difficult to call system commands. The only workaround is
to set LC_ALL to a known-good locale, but then your users get no benefit
from the translations of error messages and so on.
This is not easy problem. If you print localalized values, then there is
natural desire for symmetry. Hence locale specific arguments.
File name arguments: Two users use different codeset, both operates on
the same file system. They cannot cooperate without locale sensitive decoding.
There are many other scenerarion and it's generally accepted that
process arguments as well as other texts are locale specific.
I understand it makes your code more difficult but nobody says doing
things right is easy. (You still have to format float to string when
building execve() arguments. sprintf() respects locale. Just setlocale()
at the beginning of your main()).
-- Petr
3:07 a.m.
On Thu, Jan 31, 2013 at 12:05:16AM +0100, Benny Amorsen wrote:
This makes it difficult to call system commands. The only workaround
is
to set LC_ALL to a known-good locale, but then your users get no benefit
from the translations of error messages and so on.
You should *always* set LC_ALL=C when running an external command from
another program (and most probably from a shell script too).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
9:04 a.m.
On 31 January 2013 09:07, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Thu, Jan 31, 2013 at 12:05:16AM +0100, Benny Amorsen wrote:
> This makes it difficult to call system commands. The only workaround is
> to set LC_ALL to a known-good locale, but then your users get no benefit
> from the translations of error messages and so on.
You should *always* set LC_ALL=C when running an external command from
another program (and most probably from a shell script too).
I can imagine the problem is general (e.g. programs that need to deal
with real scalar numbers), but is interpreting IP addresses according
to locale decimal separators actually correct? The '.' in 127.0.0.1 or
Ubuntu 10.03 doesn't mean the same thing as in 3/2=1.5.
--
imalone
http://ibmalone.blogspot.co.uk
9:06 a.m.
On 31 January 2013 15:04, Ian Malone <ibmalone(a)gmail.com> wrote:
On 31 January 2013 09:07, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> On Thu, Jan 31, 2013 at 12:05:16AM +0100, Benny Amorsen wrote:
>> This makes it difficult to call system commands. The only workaround is
>> to set LC_ALL to a known-good locale, but then your users get no benefit
>> from the translations of error messages and so on.
>
> You should *always* set LC_ALL=C when running an external command from
> another program (and most probably from a shell script too).
>
I can imagine the problem is general (e.g. programs that need to deal
with real scalar numbers), but is interpreting IP addresses according
to locale decimal separators actually correct? The '.' in 127.0.0.1 or
Ubuntu 10.03 doesn't mean the same thing as in 3/2=1.5.
Before anyone else replies... -i to ping is an interval, not an
address. So 0.1s=100ms is potentially translatable. Though I'm not
sure localisation should really trump functionality in quite this way.
--
imalone
http://ibmalone.blogspot.co.uk
9:37 a.m.
On Thu, 2013-01-31 at 09:07 +0000, Richard W.M. Jones wrote:
On Thu, Jan 31, 2013 at 12:05:16AM +0100, Benny Amorsen wrote:
> This makes it difficult to call system commands. The only workaround is
> to set LC_ALL to a known-good locale, but then your users get no benefit
> from the translations of error messages and so on.
You should *always* set LC_ALL=C when running an external command from
another program (and most probably from a shell script too).
Except when you shouldn't ...
If you are getting arguments that are locale dependent changing the
locale will do you more harm than good, so now you need to parse
arguments before changing locale, assuming you know what the locale of
the arguments is and how to translate them to the C locale.
System commands should probably not change their syntax based on locale.
Ping can very well document that the -i argument takes an interval using
C locale and not do locale dependent parsing. It would be much more
robust and if you are good enough to use the -i switch you probably know
how to type 0.1 instead of 0,1 (or whatever format is in your locale) as
well.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:43 a.m.
Simo Sorce (simo(a)redhat.com) said:
> You should *always* set LC_ALL=C when running an external
command from
> another program (and most probably from a shell script too).
Except when you shouldn't ...
If you are getting arguments that are locale dependent changing the
locale will do you more harm than good, so now you need to parse
arguments before changing locale, assuming you know what the locale of
the arguments is and how to translate them to the C locale.
System commands should probably not change their syntax based on locale.
Ping can very well document that the -i argument takes an interval using
C locale and not do locale dependent parsing. It would be much more
robust and if you are good enough to use the -i switch you probably know
how to type 0.1 instead of 0,1 (or whatever format is in your locale) as
well.
Right, output should be locale specific. Input command line args... seems
specious.
Bill
11:05 a.m.
On Thu, Jan 31, 2013 at 11:43:44AM -0500, Bill Nottingham wrote:
> C locale and not do locale dependent parsing. It would be much
more
> robust and if you are good enough to use the -i switch you probably know
> how to type 0.1 instead of 0,1 (or whatever format is in your locale) as
> well.
Right, output should be locale specific. Input command line args... seems
specious.
I'd say "road to madness". If the args are to be locale-specific, why not
the options too? And the command names, for that matter.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:06 p.m.
Matthias Clasen (mclasen(a)redhat.com) said:
----- Original Message ----
>
> Right, output should be locale specific. Input command line args...
> seems
> specious.
Until you put a pipe between and turn the outputs of command a into inputs of command
b...
But, as said earlier, it's common admin practice to use LC_ALL=C for
command pipes and screenscraping. It's certainly not (at least, I thought)
common practice that they need to do this for things they pass on
the command line.
Bill
2:44 p.m.
On 01/31/2013 06:01 PM, Matthias Clasen wrote:
----- Original Message ----
>
> Right, output should be locale specific. Input command line args...
> seems
> specious.
Until you put a pipe between and turn the outputs of command a into inputs of command
b...
It's a fair point.
I.E. I/O doesn't round trip here:
$ LC_NUMERIC=de_DE env printf "%f\n" 0.1 $(LC_NUMERIC=de_DE env printf
"%f\n" 0.1)
0,100000
printf: 0,100000: value not completely converted
0,000000
I suppose commands might only enable locale specific output if
output is to a tty, though that brings other inconsistencies.
thanks,
Pádraig.
2:44 p.m.
Matthias Clasen <mclasen(a)redhat.com> writes:
Until you put a pipe between and turn the outputs of command a into
inputs of command b...
People will generally be aware that output is locale-dependent. That is
most of the point of having locales at all.
Setting LC_ALL=C is not a nice option. That would mean that I have to
redo all localization (translate the output) when I call it and intend
to return the output to the user in the appropriate language. This is at
best difficult. I also have to redo sorting and so on.
All this so that people can use decimal comma instead of decimal
point... Are there other decimal separators in use? Can we patch iputils
to accept both comma and dot in all locales?
/Benny
1:05 a.m.
Richard W.M. Jones wrote:
You should *always* set LC_ALL=C when running an external command
from
another program (and most probably from a shell script too).
I think LC_NUMERIC is probably what's wanted in this case, not LC_ALL.
Still, command-line arguments depending on LC_NUMERIC (or worse,
LC_MESSAGES, which would be entirely the wrong setting to key this off) is
very broken.
Kevin Kofler
12:25 p.m.
On 01/30/2013 11:05 PM, Benny Amorsen wrote:
Apparently ping has now started interpreting its command line
arguments
depending on locale. I.e. ping -i 0.1 no longer works in locales where
comma is the decimal separator.
This makes it difficult to call system commands. The only workaround is
to set LC_ALL to a known-good locale, but then your users get no benefit
from the translations of error messages and so on.
Is Linux really doomed to repeat the mistakes made by Visual Basic more
than a decade ago?
Yes this is a slippery slope.
ping is definitely wrong to do this IMHO.
A less clear cut example is printf(1).
POSIX states that LC_NUMERIC controls the format
of the numbers _written_.
In coreutils we're careful to reset to the C locale
so that strtod etc. work consistently.
Just testing bash here shows it was a different interpretation
which I would deem not what POSIX intended:
# coreutils
$ LC_NUMERIC=de_DE env printf "%f\n" 0.1
0,100000
$ LC_NUMERIC=de_DE env printf "%f\n" 0,1
printf: 0,1: value not completely converted
0,000000
# bash
$ LC_NUMERIC=de_DE printf "%f\n" 0,1
0,100000
$ LC_NUMERIC=de_DE printf "%f\n" 0.1
bash: printf: 0.1: invalid number
0,000000
cheers,
Pádraig
4098
days inactive
4103
days old
13 comments
10 participants
participants (10)
-
Benny Amorsen -
Bill Nottingham -
Ian Malone -
Kevin Kofler -
Matthew Miller -
Matthias Clasen -
Petr Pisar -
Pádraig Brady -
Richard W.M. Jones -
Simo Sorce