Re: declare -F incorrect line number

[Martin D Kealey]

You do realize that there are no "nested functions" in bash, right?


Graycat, talk to me on Libera if you really doubt my understanding.

All functions exist in a single, global function namespace.
>
> unicorn:~$ bash
> unicorn:~$ f() { g() { echo I am g; }; }
> unicorn:~$ f
> unicorn:~$ type g
> g is a function
> g ()
> {
>     echo I am g
> }
>

Of course, that's exactly the behaviour I want (when I don't write unset
-f).

Functions are never "local".


My phrasing "would be" should make clear that it was a proposal (albeit
somewhat flippant) and not a description of existing behaviour.

Such "inner" functions would be no more or less "local" than variables
declared the same way: their existence would end when the outer function
returns. The main difference would be saving and restoring any outer
definition.

The degenerate approach of putting unset -f at the end of the function is
simply a matter "tidiness", not leaving junk around when it shouldn't be
used.

"There are no nested functions" needs to be accompanied by a precise
definition of "nested" means, as there are at least 3 distinct concepts
upon which to base a definition.

1. gaining access to the outer function's private settings (trivially
possible via dynamic scope when the outer function is active, and never
possible otherwise)
2. gaining access to the outer function's private settings and forming a
closure to keep that access even after the outer function returns (never
possible in Bash because dynamic scope doesn't work that way)
3. simply written one inside the other (possible as demonstrated by your
own example above);
4. being hidden except when inside the outer function (always possible with
unset -f or with the proposed function -L, never possible otherwise)

-Martin