On Thu, Nov 8, 2018, 3:48 PM Eric Blake wrote:
> If the n operand is invalid or is greater than "$#", this may be
> considered a syntax error and a non-interactive shell may exit; if the
> shell does not exit in this case, a non-zero exit status shall be
> returned.
This seems to say that
On 11/8/18 3:37 PM, Eric Blake wrote:
> If I'm reading POSIX correctly, shift is a special built-in utility, and if
> '$#' is 0 or 1, then 'shift 2' counts as a utility error that shall exit
> the shell, per the table in 2.8.1 Consequences of Shell Errors:
>
>
If I'm reading POSIX correctly, shift is a special built-in utility, and
if '$#' is 0 or 1, then 'shift 2' counts as a utility error that shall
exit the shell, per the table in 2.8.1 Consequences of Shell Errors:
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
> 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
> 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
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
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
