bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EPOCHREALTIME


From: Greg Wooledge
Subject: Re: EPOCHREALTIME
Date: Thu, 19 Aug 2021 10:42:43 -0400

On Thu, Aug 19, 2021 at 10:30:39AM -0400, Chet Ramey wrote:
> On 8/19/21 9:41 AM, Léa Gris wrote:
> > This will fail because of questionable design decision of having a mutable
> > argument format:
> > 
> > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
> > 
> > Note how the format indicator still use a dot, but the argument format's
> > decimal separator is that of the system's locale.
> 
> That's not a decimal point. The `2.4' is not some sort of decimal or
> floating point number. The dot just separates the field width from the
> precision.
> 
> If the argument is, in fact, a floating point number with a radix
> character, the radix character is appropriately locale-dependent.

What Chet said is correct, as far as it goes.  If you feed numbers like
"3,14159" to printf under a locale where "," is the radix character, it
works correctly.

The problem is that not all of the Unix/Linux tools are on the same page.

unicorn:~$ LC_NUMERIC=fr_FR.utf8 bash -c 'printf "Pi: %2.4f\n" "$(bc -l <<< 
"4*a(1)")"'
bash: line 1: printf: 3.14159265358979323844: invalid number
Pi: 3,0000

Despite the locale setting, bc(1) produced a number with "." as the
radix character, which bash's printf refused to acknowledge.

unicorn:~$ LC_NUMERIC=fr_FR.utf8 bc -l <<< '4*a(1)'
3.14159265358979323844

This is acknowledged in the POSIX documentation.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html#tag_20_09_16

  The bc utility always uses the <period> ( '.' ) character to represent
  a radix point, regardless of any decimal-point character specified as
  part of the current locale. In languages like C or awk, the <period>
  character is used in program source, so it can be portable and
  unambiguous, while the locale-specific character is used in input and
  output. Because there is no distinction between source and input in
  bc, this arrangement would not be possible. Using the locale-specific
  character in bc's input would introduce ambiguities into the language

So, it seems they did it on purpose.  I'm not sure what your best choice
would be, if you happen to be in a comma-as-radix part of the world.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]