help-bash
[Top][All Lists]
Advanced

[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
>
>


reply via email to

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