You would have to pass the argument, parse it, and determine what to do.
Back to the original problem - Why would you not simply embed your UDFs in the script, or specify a UNC path to them so they are always available? The point I was making in my earlier post is that your script was not finding the external UDFs.. the answers to those questions would have shown them to be in two different places. 
One method to resolve this is to use a "kixlib" share to host your UDFs. This folder is readable by all so any script can load UDFs. I would NOT hard-code this, but create a system environment var (via GPO) called KIXLIBPATH that would be referenced by your scripts. Thus, it could be easily relocated with no code changes. ie: Call "%KIXLIBPATH%\somefunc.udf"
Personally, I never use external UDFs. If I were to update a UDF in a public library, I would have to locate and test every app that depended on that UDF. I use KGen to resolve dependencies and embed the UDFs as needed. This way, there's no dependency on external UDFs, and no potential for problems when updating UDFs. I can re-generate the scripts as time permits and test the effect and compatability of the new UDF without affecting production. KGen is part of the KixDev package on my web site. It also produces logs that can be scanned to identify which scripts rely on updated UDFs, and performs a sanity check as scripts are generated.
Glenn
_________________________
Actually I
am a Rocket Scientist!
