Local variables for nested function calls

[eduardo-chibas]

Are numbers usually declared with

num=5

Is there any advantage using

declare -i num




> Sent: Thursday, July 29, 2021 at 7:57 AM
> From: eduardo-chibas@caramail.com
> To: "Greg Wooledge" <greg@wooledge.org>
> Cc: help-bash@gnu.org
> Subject: Local variables for nested function calls
>
> > Sent: Thursday, July 29, 2021 at 6:59 AM
> > From: "Greg Wooledge" <greg@wooledge.org>
> > To: help-bash@gnu.org
> > Subject: Re: Local variables for nested function calls
> >
> > On Wed, Jul 28, 2021 at 08:46:56PM +0200, eduardo-chibas@caramail.com wrote:
> > > The problem started with a function `plist` that calls another function 
> > > `region`.
> > >
> > > ----- function plist -----
> > >
> > > ropts=("$@")
> > >
> > > # read function arguments here
> > > "-d")
> > >   local -r dpath="$2" ; shift 2 ;;
> > >
> > > local fdir=${dpath:-$PWD}
> > >
> > > region "${ropts[@]}"
> > >
> > > ----- plist ends here -----
> >
> > You have ropts as non-local variable here, FYI.  That may or may not
> > be what you want.
> >
> > > ----- function region -----
> > >
> > > # read function arguments here
> > >  "-d")
> > >     local fdir=$2 ; shift 2 ;;
> > >
> > > : "${fdir:="${@:$#}"}"}
> > >
> > > ----- region ends here -----
> >
> > > When I was calling `plist` without the -d option, and subsequently calling
> > > `region`, the value of `fdir` was being set to `$PWD`, rather than the 
> > > last
> > > argument passed to `region`.
> >
> > If you don't include the -d option, then you're skipping over the
> > "local fdir" in the second function, which means it's going to use dynamic
> > scope to find the fdir variable in the first function.
> >
> > > This means that I have to declare my variables local without setting them
> > > first.
> >
> > Well, yeah.  If region is supposed to have its own local fdir which is
> > independent of the one in plist, then you should declare fdir in region.
> > And not only when the -d option is given.
> >
> > As a general programming principle, you've got a block of code which
> > has a local variable defined inside it, which is great.  But then
> > you're using the variable after that block of code has terminated.
> > That's *not* great.  In some languages, that would be an error (the
> > compiler or interpreter would yell at you).  In bash, it's not an error;
> > you have to catch it yourself.
>
> When I use
>
> local this that
>
> `this` and `that` are unset as expected.  At first I thought the command
>
> that=${this:-8}
>
> would not set the default because `this` was defined as local.
>
>
> > If fdir is supposed to be local throughout the entire function, then I'd
> > declare it at the *top* of the function.  Or as close to the top as you
> > can reasonably make it.
> >
> > > But then I see no point of using parameter expansion such as `: 
> > > "${fdir:="${@:$#}"}"}`
> > > to set defaults because `fdir` would already be defined when I use the 
> > > local declaration
> > > within `region`.
> >
> > ... I still don't know what you're trying to *do*, though.
> >
> > I don't know what "fdir" even stands for, or why you're setting it, or
> > why you're setting it a second time, or how you use it.
> >
> > That makes it hard to give advice beyond generalities.
> >
> >
>
>