On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
> > > This change will break scripts that use $((10#$somevar)) to cope with
> > > somevar having leading zeroes OR BEING EMPTY.
Beside the point, but I wanted to point out how easy this is to work around.
$ number=0196
$ unset somevar
$ printf '%s\n' "$(( 10#${number} ))"
196
$ printf '%s\n' "$(( 10#${somevar} ))"
-bash: 10#: invalid integer constant (error token is "10#")
$ printf '%s\n' "$(( 10#0${number} ))"
196
$ printf '%s\n' "$(( 10#0${somevar} ))"
0
$ printf '%s\n' "$(( 10#${number:-0} ))"
196
$ printf '%s\n' "$(( 10#${somevar:-0} ))"
0
Re: maintaining Bash scripts across versions of Bash, here's what I
do. I implement everything in the earliest version of Bash I care to
support, Bash 4.2 on RHEL 7. That sits in my bash-4.2 branch in Git.
Then I've got a bash-4.4 branch and a rhel-9 branch. As I find little
improvements I can only make in later versions of Bash, I'll implement
those changes in the first branch where they are supported. Besides
that, everything I do in the bash-4.2 branch is going to get merged
into the bash-4.4 branch, and from there into the rhel-9 branch.
Then I don't have a reason to wait a decade to take advantage of new
Bash features, while Bash installations that support them slowly
become the norm. The changes in my scripts, at least, going from
bash-4.2 to rhel-9 are pretty minimal. So implementing little things
as I come across them and dealing with some merge conflicts isn't a
big deal.
That said, this is not a large codebase, and I'm not aware of anything
in the bash-4.2 branch that wouldn't work under RHEL 9.
Zack
