[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scientific notation in Bash
From: |
Ante Bilandzic |
Subject: |
Re: scientific notation in Bash |
Date: |
Thu, 17 Mar 2022 12:47:37 +0100 |
On Tue, Mar 15, 2022 at 2:35 PM Greg Wooledge <greg@wooledge.org> wrote:
> 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.
>
Thanks for further clarifications!
In the meantime, I hit at 'numfmt' utility which can sanitize the
"human-readable format", which I also need frequently:
$ numfmt --from=si <<< 0.44K
440
$ numfmt --from=si <<< 0.123G
123000000
Unfortunately, it doesn't support 'e' and 'E' notation, but it seems
natural to me to extend this utility also for that case. I could e.g. have
a personal Bash function 'Numfmt', which would use transparently all
available functionality of native 'numfmt' + a few specific additional
thingies I would need.
Cheers,
Ante
> 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
>
>