Re: scientific notation in Bash

[Greg Wooledge]

On Tue, Mar 15, 2022 at 02:16:29PM +0100, Ante Bilandzic wrote:
> On Tue, Mar 15, 2022 at 1:47 PM Tapani Tarvainen <bash@tapanitarvainen.fi>
> wrote:
> > Bash can do it with the printf builtin:
> >
> > $ printf "%.0f\n" 4.4e5
> > 440000
> > $ printf "%.0f\n" 4.4e9
> > 4400000000
> >
> > So instead of Var=44e1 you could do
> >
> > printf -v Var "%.0f" 44e1
> >
> 
> Thanks!
> 
> This works but only as a workaround, because it's clearly impractical and
> inefficient to have such a conversion explicitly written for each integer
> variable, whether or not it contains the integer written in sci. notation.

I strongly disagree.

You are attempting to feed user inputs (whether they're from a file, from
keyboard input, from environment variables, from a network service, etc.)
into a bash math context.  These inputs need to be *sanity-checked*
and then, if necessary, *converted* into correct, usable numeric strings.

If you don't perform the check and the conversion, you get MAJOR problems.
You've already identified one of them -- the value isn't recognized at
all, and you get an error message.  Here are some others you haven't
talked about yet:

1) Implicit octal conversion due to leading zeroes.

   unicorn:~$ n=0314
   unicorn:~$ echo $((n))
   204

2) Failed octal conversion due to leading zeroes and digits over 7:

   unicorn:~$ n=0318
   unicorn:~$ echo $((n))
   bash: 0318: value too great for base (error token is "0318")

3) Code injection due to malicious input.

   unicorn:~$ n='a[$(date >&2)0]'
   unicorn:~$ echo $((n))
   Tue Mar 15 09:26:26 EDT 2022
   0