Autoload vs regular function

Autoload vs regular function

[Sebastian Gniazdowski]

Hello,
I tried to do the following on my series of autoload functions (their
names begins with "n-" prefix):

#!/bin/zsh

local PLUGIN_FILE="znt.plugin.zsh"
rm -f "$PLUGIN_FILE"

for i in n-*; do
    echo "$i() {" >>"$PLUGIN_FILE"
    cat "$i" >>"$PLUGIN_FILE"
    echo "}" >>"$PLUGIN_FILE"
    echo >>"$PLUGIN_FILE"
done

to have plugin for the various current frameworks. In result the code
gives file with series of functions. The technique seems to work, but
are there any pitfalls about functions declared in this way instead of
using autoload and separate files? Is this enough to have plugin for
e.g. antigen?

Best regards,
Sebastian Gniazdowski

Re: Autoload vs regular function

[Bart Schaefer]

On Sep 18,  8:34am, Sebastian Gniazdowski wrote:
}
} are there any pitfalls about functions declared in this way instead of
} using autoload and separate files? Is this enough to have plugin for
} e.g. antigen?

There aren't any pitfalls to this, except that the file has to be
sourced (i.e., all the functions fully defined in shell memory) unless
there is a single entry-point function whose name can be the same as
the basename of the file, and thereby trigger loading the whole thing.

E.g. the _git file that handles completion for all the git subcommands
has a whole slew of helper functions, none of which are loaded until
an attempt to complete for "git" is done, at which time the _git entry
point function loads all of them.

Re: Autoload vs regular function

[Ray Andrews]

On 09/18/2015 10:15 AM, Bart Schaefer wrote:
> On Sep 18,  8:34am, Sebastian Gniazdowski wrote:
> }
> } are there any pitfalls about functions declared in this way instead of
> } using autoload and separate files? Is this enough to have plugin for
> } e.g. antigen?
>
> There aren't any pitfalls to this, except that the file has to be
> sourced (i.e., all the functions fully defined in shell memory) unless
> there is a single entry-point function whose name can be the same as
> the basename of the file, and thereby trigger loading the whole thing.
>
> E.g. the _git file that handles completion for all the git subcommands
> has a whole slew of helper functions, none of which are loaded until
> an attempt to complete for "git" is done, at which time the _git entry
> point function loads all of them.
Can you rough in an example of that for us Bart?  Sounds like an elegant 
idea.  I wonder
if it is possible that when one types a command that is not found, it 
could trigger
a sort of search in some directory for a script that would itself source 
the very command
not found and then run it?  Sorta a reinvention of autoload but maybe more
transparent.

>

Re: Autoload vs regular function

[Bart Schaefer]

On Sep 18, 11:45am, Ray Andrews wrote:
}
} Can you rough in an example of that for us Bart?  Sounds like an elegant 
} idea.

Functions/Misc/tetris in the zsh distribution is a perfect example of
this already.  It defines a whole bunch of helper functions (most of
which end up becoming zle widgets) and a single entry point function
"tetris" which kicks the whole thing off.

Note at the very end of Functions/Misc/tetris, the function that it
defined is explicitly called.  This is so tetris can be autoloaded in
the default zsh style.  If you do "autoload -k tetris" the command is
run twice.  (Many autoloadable functions in the zsh distribution test
for KSH_AUTOLOAD before calling themselves this way; tetris probably
ought to as well, but currently doesn't.)

} I wonder if it is possible that when one types a command that is not
} found, it could trigger a sort of search in some directory for a
} script that would itself source the very command not found and then
} run it? Sorta a reinvention of autoload but maybe more transparent.

Recent zsh support a command_not_found_handler function which is run
if a the searches of $fpath and $path do not find anything.  So you
can do this by building a custom search in command_not_found_handler.
I don't know that this any more "transparent" than otherwise.  Also
the command_not_found handler runs after the parent shell has forked,
so anything it loads does not appear in the parent.

E.g. to always attempt to load functions from a .zwc file in the
current working directory, you could:

    command_not_found_handler () {
        FPATH=$PWD autoload +X $1
        "$@"
    }

Similarly if you don't like zsh's way of handling autoloads, you can
do you own like this:

    auto_load_me () {
	FPATH=/my/custom/fpath autoload -X
    }

This is [almost!] the same as writing

    autoload auto_load_me

except that the custom fpath is asserted.  I say "almost" because things
like sticky emulation get handled a little differently when using the
"autoload -X" command, but that is pretty esoteric.  Of course you can
throw in other things besides just fpath changes, you have a whole
function body to play with, but at some point you're just ruining the
whole purpose of autoload and might as well define the real function.

-- 
Barton E. Schaefer

simple question regarding local variables

[Ray Andrews]

I should know this:

Say several functions will use the same set of variables, so you want
some way of auto creating them for each function, *but* they must be
local to each function.

This works:

'test1' is a script:

       #!/usr/bin/zsh
       local variable=howdy
       local anothervariable=whatever

    local foo=FOO
    local bar=BAR
    local baz=BAZ
    # and so on ... I create all my variables in the script.


'test2' is a function that sources 'test1':

    test2 ()
    {
       varis variable
       .  ./test1
       varis variable
    }


('varis' simply prints the name and the value of variables.)

A run:

    $ test2; varis variable
    $variable is: ""
    $variable is: "howdy"
    $variable is: ""


... just as I want, sourcing 'test1' creates local variables in my 
function, but why does it
work?  sourcing I understand to create a child shell, thus how is it 
that after 'test1'
returns, that it's local variables are known to 'test2'?  Exactly as I 
want, '$variable'
evaporates after 'test2' returns, so it's local.  I like it, but I can't 
explain it.

Re: simple question regarding local variables

[Bart Schaefer]

Actually this is a simple question about sourcing.

On Sep 19,  9:23am, Ray Andrews wrote:
}
} sourcing I understand to create a child shell

No, sourcing explicitly does NOT create a child shell; "source" *means*
to execute the commands in the current shell.  Running a script by its
name without sourcing is what creates a child shell.

Re: simple question regarding local variables

[Ray Andrews]

On 09/19/2015 09:32 AM, Bart Schaefer wrote:
> Actually this is a simple question about sourcing.
>
> On Sep 19,  9:23am, Ray Andrews wrote:
> }
> } sourcing I understand to create a child shell
>
> No, sourcing explicitly does NOT create a child shell; "source" *means*
> to execute the commands in the current shell.  Running a script by its
> name without sourcing is what creates a child shell.
>
Of course.  Pardon, I knew that at one time. Functions, sourced scripts
and executed scripts. Over the summer I forget half of what I learned the
previous year.