Even though bash is not my favorite programming language, I end up writing a bit of code in it. It's just super practical to have something in bash if you can. I mentioned in the past how it's a good idea to avoid unnecessary cpu/io while initializing the shell by doing deferred aliasing. That solves the alias problem, but I also have a bunch of bash code in terms of functions. So I was thinking the same principle could be applied again.
Let's use findpkgs as an example here. The function is defined in a separate file and the file is source'd. But this means that every time I start a new shell session the whole function has to be read and loaded into memory. That might not be convenient if there are a number of those. networktest, for instance, defines four function and is considerably longer.
So let's "compile to bytecode" again:
findpkgs ()
{
[ -f ~/.myshell/findpkgs.sh ] && . ~/.myshell/findpkgs.sh;
findpkgs $@
}
When the function is defined this way, the script actually hasn't been sourced yet (and that's precisely the idea), but it will be the minute we call the function. This, naturally, will rebind the name findpkgs, and then we call the function again, with the given arguments, but this time giving them to the actual function.
Okay, so that was easy. But what if you have a bunch of functions loaded like that? It's gonna be kinda messy copy-pasting that boilerplate code over and over. So let's not write that code, let's generate it:
lazyimport() {
# generate code for lazy import of function
function="$1";shift;
script="$1";shift;
dec="$function() {
[ -f ~/.myshell/$script.sh ] && . ~/.myshell/$script.sh
$function \$@
}"
eval "$dec"
}
Don't worry, it's the same thing as before, just wrapped in quotes. And now we may import all the functions we want in the namespace by calling this import function with the name of the function we want to "byte compile" and the script where it is found:
## findpkgs.sh
lazyimport findpkgs findpkgs
## networktest.sh
lazyimport havenet networktest
lazyimport haveinet networktest
lazyimport wifi networktest
lazyimport wifiscan networktest
## servalive.sh
lazyimport servalive servalive
So let's imagine a hypothetical execution. It goes like this:
- Start a new bash shell.
- Source
import.sh where all this code is.
- On each call to
lazyimport a function declaration is generated, and eval'd. The function we want is now bound to its name in the shell.
- On the first call to the function, the generated code for the function is executed, which actually sources the script, which rebinds the name of the function to the actual code that belongs to it.
- The function is executed with arguments.
- On subsequent executions the function is already "compiled", ie. bound to its proper code.
So what happens, you may wonder, in cases like the above with networktest, where several mock functions are generated, all of which will source the same script? Well nothing, whichever of them is called first will source the script and overwrite all the bindings, remember? It only takes one call to whichever function and all of them become rebound to the real thing. So all is well. :)
January 30th, 2010
