On 11/8/18 10:28 AM, Great Big Dot wrote:
>> It should expand to the empty string in all these cases.
>
> Oh yeah, right, because a function isn't even running. Duh. All my comments
> about expected behavior should be inverted, then, I guess. Out of
> curiosity, do you have any idea what's causing
> It should expand to the empty string in all these cases.
Oh yeah, right, because a function isn't even running. Duh. All my comments
about expected behavior should be inverted, then, I guess. Out of
curiosity, do you have any idea what's causing bash to *sometimes*
correctly conclude that FUNCNA
> Since your example doesn't show a function being defined or called, I
> would expect it to show only empty strings.
Oh yeah, right. For some reason I thought the part about "main" still
applied. But the actual expected behavior doesn't occur either;
"${FUNCNAME[0]}" and "${FUNCNAME[*]}" are both
On 11/8/18 1:15 AM, Great Big Dot wrote:
> Bash Version: 4.4
> Patch Level: 23
> Release Status: release
>
> Description:
> The builtin array variable FUNCNAME (which provides a way to trace the
> stack of functions called so far) appears to be unset according to certain
> bash expansions, even w
On Thu, Nov 08, 2018 at 01:15:56AM -0500, Great Big Dot wrote:
> Description:
> The builtin array variable FUNCNAME (which provides a way to trace the
> stack of functions called so far) appears to be unset according to certain
> bash expansions, even when it isn't. If the following code is saved t
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'