Re: Is the function $f defined and is not an autoload stub?

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Thu, Jun 16, 2016 at 09:16:14 -0700:
> On Jun 15, 11:24pm, Daniel Shahaf wrote:
> }
> } I'd like to test whether the shell function $f is available (callable).
> 
> Addressing the question of how to do it *now*, I think I'd choose to
> do the test in a subshell so that testing doesn't change the state
> of the calling shell.  If that's acceptable, then:
> 

No objections to a subshell.  (I'd like to minimise the number of forks,
but a subshell v. a command substitution shouldn't make a difference.)

>     if [[ "$functions[$f]" != *"builtin autoload -X" ]] ||
>        ( unfunction -- "$f" && autoload +X -- "$f" ); then
>         print "Hooray, $f is callable"
>     fi
> 
> I prefixed the "builtin ..." with a * just in case at some point in
> the future we begin including the "# undefined" comment in the body
> for $functions[$f] the same way we do for $(functions $f).
> 

Thanks, this is saner.

> I suppose for consistency "autoload xyz" should return false if the
> function is already fully defined (though what to do in the case of
> "autoload xyz pdq" where one is defined and the other is not is a
> bit ambiguous even for the +X case).  Right now "autoload xyz" never
> returns nonzero that I can tell.

So, if I read you correctly, this would enable the idiom 'if autoload +X
$f; ! autoload $f; then' to test for fully-definedness?

I _would_ like having an API for this (as opposed to testing stringified
function bodies).  I don't know what it should look like, though; I just
know that I have a need for it.

The proposed would cause behaviour changes in certain cases: for
example, in the case of a plugin that calls 'autoload add-zsh-hook &&
add-zsh-hook foo bar' with errexit or printexitvalue in effect.  (Yes,
people do this: the idiom I learnt was "autoload foo && foo".)
[I'm not saying this is or isn't a problem; I'm simply stating a fact
about the proposed change.]

Cheers,

Daniel