A few words about kshautoload

A few words about kshautoload

[Bart Schaefer]

I was reading a posting on comp.unix.shells a few weeks ago in which the
author was explaining that it's possible to implement job control and a
number of other "advanced" shell features by appropriate programming of
pure Bourne shell.  (If I recall correctly, the only concession was that
the shell had to implement user-defined functions if you didn't like to
call your shell functions with a leading `$' on the name.)

Probably it should have been obvious to me before, but it took reading
this article to make me realize that the ksh autoloading model is designed
so that the files can be parsed with the `.' command without the result of
executing the function body in the context of the caller.  Because in the
absence of an `autoload' builtin, the way to implement your own autoloader
is to create function stubs that read in the "real" definition with `.',
and then call the redefined function iff the parse is successful.

Thus in ksh the autoload command is nothing more than a conversion of a
useful scripting idiom into C code, and uses the syntax of the original
shell programming technique.

Zsh, on the other hand, takes the view that the files should be executable
as standalone shell scripts.  This spoils the `.' trick, because the code
begins executing immediately; you don't get to attempt a full parse first.
You can still implement your own autoloader if you're willing to scarf up
the whole file into a parameter and `eval' it, but it's messier than the
ksh-equivalent version.  In the zsh model, autoload can be efficient only
as a builtin.

Which is why we needed to invent `autoload -X' and `autoload +X', and is
also why those options work badly-if-at-all for kshautoload-ed functions.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net