Re: Creating A Clean Environment For Autoloaded Functions

[Russell Harmon <russ@xxxxxxxxxxxxxx>]

On Sun, Dec 30, 2012 at 2:20 PM, Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Dec 30,  4:44am, Russell Harmon wrote:
>>
>> If I want to write a function which can be autoloaded, how can I
>> prevent functions defined outside of my function from being accessible
>> from within my function? For example, I have a function ls { gls "$@"
>> }, and I know of no way to prevent that function from leaking into the
>> definition of all the functions I've autoloaded which use ls.
>
> This amounts to asking how to violate a basic tenet of shell function
> behavior.  They're supposed to act like commands that are always at the
> front of the search path, and the search path doesn't change based on
> the order in which every other command was added to it.
>
> The way you avoid this is to write every function that explicitly does
> not want this behavior so as to explicitly override it; for examply by
> using "command ls" instead of "ls".
>
> However, you could do something like this, assuming zsh/parameter is
> loaded:
>
>     ls() {
>       if (( $#funcstack > 1 ))
>       then command ls "$@"
>       else gls "$@"
>       fi
>     }
>
> This will prevent gls from being run inside any other function, although
> it won't bypass the ls wrapper function entirely.

I guess that breaking with this particular shell idiom is what I want
to do. Otherwise, how is one supposed to be able to create
autoloadable functions with reliable and reproducible behavior? I'm
thinking to add an option to autoload to undefine all functions much
like how -U works with aliases.

Basically, I'm trying to follow what the best practices are when
writing autoloadable functions so that they will be able to run
reliably in the largest number of different environments possible.

>
>> Additionally, is it possible to zmodload a module which is
>> automatically unloaded from the environment after my function
>> completes _only if_ that module was not already loaded?
>
> There isn't a property of modules that supports this, but you can do it
> yourself explicitly with something like this:
>
>     {
>       zmodload -e zsh/mathfunc  # for example
>       local unload_mathfunc=$?
>       zmodload zsh/mathfunc
>
>       : do what you need to with math functions
>
>     } always {
>       (( unload_mathfunc )) && zmodload -u zsh/mathfunc
>     }
>
> If the zsh/parameter module is not itself one of the ones you care about
> unloading in this way, you can be more generic:
>
>     {
>       zmodload zsh/parameter
>       local -a existing_modules
>       existing_modules=( ${(k)modules[(R)loaded]} )
>
>       : do whatever zmodloads you want ...
>
>     } always {
>       # Requires zsh 5.0, otherwise you need a loop
>       zmodload -u ${(k)modules[(R)loaded]:|existing_modules}
>     }
>
> I'm not sure that zmodload is clever enough to notice that inter-module
> dependencies have been satisfied by the list provided to -u and thus
> unload the modules in the correct order to be sure it succeeds, so a
> bit of tweaking to the above may be required for full generality.

Hmm, I think I'm realizing that loading & unloading of dependent
modules every time a function is called might not be exactly what I
want. I think what I'm looking for is more like zsh modules where you
have hook functions for when the function is loaded & unloaded so that
you can unload relevant modules when no longer needed. That has it's
own difficulties however because it'd be hard to tell if some other
function loaded after you were loaded needs a module which you are
about to unload.