Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14306 > unrolled thread

Re: Number with sign is read as octal despite a leading 10#

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Number with sign is read as octal despite a leading 10# Ilkka Virta <itvirta@iki.fi> - 2018-07-10 14:14 +0300

#14306 — Re: Number with sign is read as octal despite a leading 10#

For what it's worth, ksh and zsh seem to interpret  10#-0159
as negative one-hundred and fifty-nine:

$ ksh -c 'for a do a="10#$a"; printf "%s " $((a + 1)); done; echo' \
   sh +159 +0159 -159 -0159
160 160 -158 -158
$ zsh -c 'for a do a="10#$a"; printf "%s " $((a + 1)); done; echo' \
   sh +159 +0159 -159 -0159
160 160 -158 -158

$ ksh --version
   version         sh (AT&T Research) 93u+ 2012-08-01
$ zsh --version
zsh 5.3.1 (x86_64-debian-linux-gnu)


On 10.7. 13:44, Ilkka Virta wrote:
> I think the problematic case here is when the number comes as input from 
> some program, which might or might not print a leading sign or leading 
> zeroes, but when we know that the number is, in any case, decimal.
> 
> E.g. 'date' prints leading zeroes, which is easy enough to handle:
> 
> hour=$(date +%H)
> 
> hour=${hour#0}         # remove one leading zero, or
> hour="10#$hour"        # make it base-10
> 
> The latter works even with more than one leading zero, but neither works 
> with a sign. So, handling numbers like '-00159' gets a bit annoying:
> 
> $ num='-00159'
> $ num="${num:0:1}10#${num:1}"; echo $(( num + 1 ))
> -158
> 
> And that's without checking that the sign was there in the first place.
> 
> 
> Something like that will probably not be too common, but an easier way 
> to force any number to be interpreted in base-10 (regardless of leading 
> zeroes) could be useful. If there is a way, I'd be happy to hear.
> 
> 
> On 10.7. 04:37, Clint Hepner wrote:
>> The + is a unary operator, not part of the literal. Write 
>> $((+10#0034)) instead.
>>
>> -- 
>> Clint
>> On Jul 9, 2018, 9:24 PM -0400, Isaac Marcos 
>> <isaacmarcos100010@gmail.com>, wrote:
>>> Configuration Information [Automatically generated, do not change]:
>>> Machine: x86_64
>>> OS: linux-gnu
>>> Compiler: gcc
>>> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
>>> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
>>> -DCONF_VENDOR
>>> uname output: Linux IO 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
>>> (2018-05-07) x86_64 GNU/Linux
>>> Machine Type: x86_64-pc-linux-gnu
>>>
>>> Bash Version: 4.4
>>> Patch Level: 12
>>> Release Status: release
>>>
>>> Description:
>>> A value inside an arithmetic expansion is processed as octal despite 
>>> using
>>> a 10# preffix.
>>>
>>> Repeat-By:
>>> $ echo $((10#+0034))
>>> 28
>>>
>>> Fix:
>>> Extract optional sign before parsing the number, re-attach after.
>>>
>>> -- 
>>> Cases are always threesome:
>>> Best case, Worst case, and Just in case
> 
> 


-- 
Ilkka Virta / itvirta@iki.fi

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web