Local variables for nested function calls

[eduardo-chibas]

`fdir` stores the directory used for listing the contents using
head (from beginning) and tail (from end).  Region does a listing
between two arbitrary line numbers (a region) or a small region
centered around a specific search string (dynamic listing based
on pattern).

Ordinarily, I want variables to be local.  Dynamic scoping does
have many side effects, and having to continually use `local` is
somewhat bothersome.  The fact that these and the need for quoting
are defined in the posix standard means that few will rethink changing
them so me can all move on from the mistakes of the past.

> 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.
>
> 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.
>
>