Re: Suggested BASH Improvement

[Greg Wooledge]

On Wed, Sep 18, 2024 at 10:51:51 -0400, Chet Ramey wrote:
> On 9/17/24 7:50 PM, BRUCE FOWLER via Bug reports for the GNU Bourne Again
> SHell wrote:
> > An interesting problem I ran into recently:
> > I have a shell script that I run about once a month that
> > "screen-scrapes" from the output of another program using the
> > substring capability, e.g. ${data_line:12:2}. This is pulling
> > out the two-digit month ranging from "01" to "12".
> > This worked fine, even giving the right answers, for
> > months earlier in the year. Then came August, and it went
> > sideways because the leading "0" was forcing the number to be
> > interpreted as octal. My first reaction was, What's going on,
> > this has run just fine for months. The second reaction was,
> > WTF, who uses octal anymore? But I understand it is because
> > of C-language compatibility. I could use the [base#]n form
> > but that gets awkward.
> 
> Thanks for the proposal. I think the [base#]n syntax is reasonable
> here without adding a new shell option.

Do recall, however, that negative numbers break the workaround suggested
by Andreas.

    $((10#${line:12:2}))

works only for unsigned numeric values.  With a hyphen in the first
column, you get

    hobbit:~$ line=-1
    hobbit:~$ echo $((10#$line))
    bash: 10#: invalid integer constant (error token is "10#")

In <https://lists.gnu.org/archive/html/bug-bash/2018-07/msg00033.html>,
Pierre gives a workaround that includes handling of the (optional) sign:

    $((${num%%[!+-]*}10#${num#[-+]}))

Whether this is "reasonable" is of course subjective.