### doing simple math in bash :: prb with leading zero

```
Doing very simple math in bash fails if a number begins with a zero (0).
The short script below illustrates the problem:

--- begin

#!/bin/bash
#Testing number decrement because I ran into an errors
#e.g., lastmo=\$((\${lastmo}-1)) returns error:
# 09: value too great for base (error token is 09)
#This script assumes the month is September.

#Removing the initial '0' from \$lastmo fixed the prb.

lastmo=\$(date +%m) #shows current month as a number, e.g. 09
echo The \date\ command says the month is \${lastmo}

#Remove initial '0' so math in else below won't hork
#Uncomment the next 2 lines to fix error msg in else below.
#lastmo=\${lastmo#0}
#echo After trimming initial zero, lastmo is \$lastmo

year=\$(date +%Y)
echo Immediately prior to \if\ the current month is \${lastmo}

#Determine number representing previous month
if [ \${lastmo} -eq 1 ]
then
lastmo=12
year=\$((\${year} - 1))
else
echo Before calc, lastmo = \${lastmo}
lastmo=\$((\${lastmo}-1)) #doesn't work for 09
#lastmo=\$((lastmo-=1)) #another way, same result
echo After calc, lastmo = \${lastmo}
fi

#Just doing a comparison works okay for 09
val1=\$(date +%m)
echo Just doing a comparison using val1 when it is \${val1}

if [ \${val1} -eq 1 ]
then
echo Values \${val1} and 1 are the same.
else
echo Values \${val1} and 1 are different.
fi

if [ \${val1} -eq 9 ]
then
echo Values \${val1} and 9 are the same.
else
echo Values \${val1} and 9 are different.
fi

end -

This is what I get on Linux running on an i686.

Bash should be smart enough to know that 09 = 9
-- and it does sometimes, but not all the time.
Surprise!!

```

### Who handles fails to build problems for bash?

```Could not find any groups other than this for bash problems. My build is
failing with

make[1]: Leaving directory `/home/users/tovrea/BASH/build_sgi_bash/lib/tilde'
rm -f bash
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/4.3.0
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/4.3.0/32
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/lib32
-L/home/users/tovrea/local/sgi6/lib-g -O2 -o bash shell.o eval.o y.tab.o
general.o make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o variables.o
copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o
mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o
alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o  list.o
stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o
xmalloc.o  -lbuiltins -lsh -lreadline -lhistory -ltermcap -lglob -ltilde
lib/intl/libintl.a   -ldl
/home/users/tovrea/local/sgi6/bin/ld: non-dynamic relocations refer to dynamic
symbol PC
/home/users/tovrea/local/sgi6/bin/ld: failed to set dynamic section sizes: Bad
value
collect2: ld returned 1 exit status
make: *** [bash] Error 1

GNU ld (GNU Binutils) 2.19.1

Bill Tovrea

BAE Systems

16550 West Bernardo Drive
San Diego, CA 92127

Telephone: (858) 592-5292

Pager: (888) 971-4964

E-mail: george.tov...@baesystems.com

```

### Re: doing simple math in bash :: prb with leading zero

```ken wrote:
Doing very simple math in bash fails if a number begins with a zero (0).

Thanks for the report.  However it isn't a bug but simply a
misunderstanding.  Numbers starting with 0 are octal numbers not
decial numbers.  And as you know octal numbers includes zero through
seven but does not include eight or nine.

Please look at the Bash FAQ item E8.

http://www.faqs.org/faqs/unix-faq/shell/bash/

Bob

```

### Re: manpage note? weird strings that appear to be equal but create haywire comparisons?

```
Chet Ramey wrote:

Note that [[ and [ return different results when the vars are unquoted.

Yes.  There are two differences.

First, the operands in [[ do not undergo all word expansions.  The
arguments to [, since it's a builtin, do.  That doesn't really matter
to this example, but it's worth noting.

Second, the = and != operators in [[ perform pattern matching (= is
the same as ==).  You have to quote the rhs to force string matching.

In pattern matching, the backslash has a special meaning: it quotes the
next character.

---
That makes sense -- but I was attributing it to the backslash being
within double quotes vs. single quotes, paralleling the expansion
of variables.  *sigh*

So when \$v is unquoted, the pattern matcher treats the
pairs of backslashes in \$v as one backslash quoting another, and the
strings match.  When using [, bash does straight string comparison, and
the strings are not identical.

---
That, I did not know. I thought it had to do with whether or
not you enclosed the string in single quotes or double quotes there,
too...

I think I'm getting string rules from various languages confused at
times...*sigh*

```

### Re: Who handles fails to build problems for bash?

``` Could not find any groups other than this for bash problems. My build is
failing with

make[1]: Leaving directory `/home/users/tovrea/BASH/build_sgi_bash/lib/tilde'
rm -f bash
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/4.3.0
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/4.3.0/32
-L/home/users/tovrea/local/sgi6/lib/gcc/mips-sgi-irix6.5/lib32
-L/home/users/tovrea/local/sgi6/lib-g -O2 -o bash shell.o eval.o y.tab.o
general.o make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o variables.o
copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o
mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o
alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o
list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o
xmalloc.o  -lbuiltins -lsh -lreadline -lhistory -ltermcap -lglob -ltilde
lib/intl/libintl.a   -ldl
/home/users/tovrea/local/sgi6/bin/ld: non-dynamic relocations refer to
dynamic symbol PC
/home/users/tovrea/local/sgi6/bin/ld: failed to set dynamic section sizes:
collect2: ld returned 1 exit status
make: *** [bash] Error 1

The quick fix should be adding -lcurses or -lncurses (whatever works) as the
value of TERMCAP_LIB in the= Makefile.

The longer fix is to look at config.log and try and figure out why there is
(apparently) no library that contains the termcap functions, and why the
build process is not defaulting to the built-in termcap library if so.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

```

### Re: doing simple math in bash :: prb with leading zero

```
ken wrote:

Doing very simple math in bash fails if a number begins with a zero (0).
The short script below illustrates the problem:

---
Normally, a leading 0 begins an octal constant (I have been bitten
by this in the past as well...).

Where are you getting the value 'lastmo' from?

If  from 'something like date +%m', maybe you could strip

lastmo=\$(echo \$lastmo|sed -r 's/0+([0-9])/\1/')

```

### Re: doing simple math in bash :: prb with leading zero

```On Tue, 1 Sep 2009, Linda Walsh wrote:

ken wrote:
Doing very simple math in bash fails if a number begins with a zero (0).
The short script below illustrates the problem:
---
Normally, a leading 0 begins an octal constant (I have been bitten
by this in the past as well...).

Where are you getting the value 'lastmo' from?

If  from 'something like date +%m', maybe you could strip off the leading
zero?  I.e.:

lastmo=\$(echo \$lastmo|sed -r 's/0+([0-9])/\1/')

Surely you mean:

lastmo=\${lastmo#0}

--
Chris F.A. Johnson, webmaster http://woodbine-gerrard.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

```

### Re: doing simple math in bash :: prb with leading zero

```On Tue, 1 Sep 2009, ken wrote:

Doing very simple math in bash fails if a number begins with a zero (0).

Numbers beginning with 0 are base 8 (octal). 08 and 09 are not
valid octal numbers.

--
Chris F.A. Johnson, webmaster http://woodbine-gerrard.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

```

### Re: doing simple math in bash :: prb with leading zero

```ken wrote:

This is what I get on Linux running on an i686.

Bash should be smart enough to know that 09 = 9
-- and it does sometimes, but not all the time.
Surprise!!

From the bash manual:

Constants with a leading 0 are interpreted as octal numbers.  A leading 0x