mjhjmtu

It is a "feature" of the shell that a number with a leading zero is interpreted as an octal number:

$ echo "$((00100))"
64

But there is no way to disallow this "feature" in many shells, so, it becomes difficult to force the interpretation of a digit sequence as a decimal (or other base) number.

When there is only a number to convert, there are several external programs that could do the trimming:

expr "00100" + 0 
echo "00100" | sed 's/^0*//'
echo "00100" | grep -o '[^0].*$'
echo "00100" | awk 'print int($0)'
echo "00100" | perl -pe '$_=int."n";'

But it takes some time to execute them each and every time they are needed. Acumulate the use of such external tools over many calls and the delay becomes quite big. Just to measure up the delay caused, repeat the calls above a 1000 times and you will get (in sec):

expr 1.934
sed 3.450
grep 3.775
awk 5.291
perl 5.064

Of course (except expr) most tools could process a file with a 1000 lines in:

sed file 0.004
grep file 0.003
awk file 0.007
perl file 0.006

If all the individual 1000 values are available at the same point in time.

That could not be the case. So, what still remains to be answered is:

Is there a native (to the shell) way to extract an integer that is faster than calling external tools for each individual integer (not a list in a file) ?

Each call accumulates and the delay will become important.

The processing becomes more involved if the number may also have a leading sign and you want to reject invalid numbers.

Note that while $((010)) is required by POSIX to expand to 8, several shells don't do it by default (or only in some contexts) unless in a conformance mode as that's a feature you usually do not want.

With zsh, that's controlled by the octalzeroes option (off by default except in sh/ksh emulation).

$ zsh -c 'echo $((010))'
10
$ zsh -o octalzeroes -c 'echo $((010))'
8
$ (exec -a sh zsh -c 'echo "$((010))"')
8

In mksh, that's controlled by the posix option (off by default):

$ mksh -c 'echo "$((010))"'
10
$ mksh -o posix -c 'echo "$((010))"'
8

In bash, there's no option to turn it off, but you can use the $((10#010)) ksh syntax to force interpretation in decimal (also works in ksh and zsh), though in bash and mksh -o posix, $((10#-010)) doesn't work (treated as 10#0 - 010 as you can see from the expansion of $((-10#-010)) yielding -8), you need $((-10#010)) (or $((- 10#010)) for compatibility with zsh which complains about -10 being an invalid base).

$ bash -c 'echo "$((10#010))"'
10

With ksh93, compare:

$ ksh93 -c 'echo "$((010))"'
8
$ ksh93 -c '((a = 010)); echo "$a"'
8

with:

$ ksh93 -c 'a=010; echo "$((a))"'
10
$ ksh93 -c 'printf "%dn" 010'
10
$ ksh93 -c 'let a=010; echo "$a"'
10
$ ksh93 -c 'echo "$((010e0))"'
10
$ ksh93 -o letoctal -c 'let a=010; echo "$a"'
8

So at least if you're coding for any of those shells specifically, there are ways to work around that "misfeature".

But none of those would help when writing a POSIX portable script, in which case, you'd want to strip the leading zeros as you have shown.

Something similar could be done in one line with:

$ a=-00100; a=$a%"$a#[+-]"$a#"$a%%[!0+-]*"; a=$a:-0
$ echo "$a"
-100

It just takes 0.0482 for 1000 repetitions, 100 times less than using an external program.

That's based on two double parameter expansions:

1. Extract the sign:
   
   
   • 
     $a#[+-] remove the first character provided it is a sign.
   
   
   • 
     $a%"$a#[+-]" keeps the first sign provided that it is a sign.
   
   


2. Remove all leading signs and/or zeros:
   
   
   • 
     $a%%[!0+-]* remove starting at any ( not 0 or + or - ) to the end.
   
   
   • 
     $a#"$a%%[!0+-]*" remove the above, i.e., all leading zeros and signs.
   
   

That picks one sign and remove all leading zeros.
However it allows (without error):

1. Several leading signs.


2. Any characters after the leading signs and zeros.


3. An "out of range" (too big) number.

If those tests are needed, keep reading.

The number of signs could be tested with:

signs=$a%%[!+-]* 
[ $#signs -gt 1 ] && echo "$0: Invalid number $a: Too many signs"

The kind of characters allowed could be checked with:

num=$a#"$a%%[!0+-]*"

any=$num%%[!0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_]*
[ "$any" != "$num" ] && echo "$0: Invalid number $a"

hex=$num%%[!0123456789abcdefABCDEF]*
[ "$hex" != "$num" ] && echo "$0: Invalid hexadecimal number $a"

dec=$num%%[!0123456789]*
[ "$dec" != "$num" ] && echo "$0: Invalid decimal number $a"

And, finally, we can take advantage of the capacity of printf of printing a warning for numbers "out of range" (only for bases that printf understand):

printf '%d' $sign$dec >/dev/null # for a decimal number
printf '%d' "$sign0x$hex" >/dev/null # for hex numbers

Yes, all printf use %d, it is not a typo.

And, yes, all the above works in most shells that have printf.

Here is your example x1000 on my system:

$ cat shell.sh
#!/bin/dash
q=1
while [ "$q" -le 1000 ]
do
 z=-00100
 z=$z%"$z#[+-]"$z#"$z%%[!0+-]*"
 z=$z:-0
 echo "$z"
 q=$((q + 1))
done

Result:

$ time ./shell.sh >/dev/null
real 0m0.047s

Now I take issue with the sed example. I do see an example with a file, but i am
not seeing a clear reason why using a file is not acceptable. also the example
with pipe is problematic because a pipe is not needed - nor is calling sed 1000
times. if you simply cant use a file for whatever reason - a heredoc would be
fine:

cat > sed.sh <<alfa
sed 's/^0*//' <<bravo
$(yes 00100 | head -1000)
bravo
alfa

Result:

$ time ./sed.sh >/dev/null
real 0m0.047s

So on my system it is the exact same speed without the fuss.