Explain the internal working of BeanShell's command-loading mechanism?

When a script calls something that looks like a built-in command - print(), source(), frame(), and so on - BeanShell first checks whether that name matches a real Java method or a scripted method already defined in the current namespace chain; if not, it falls through to its command-resolution mechanism.

BeanShell's command resolution searches a configured set of package locations on the classpath, by convention a location like bsh/commands/, for a .bsh file whose name matches the command being called, treating that .bsh file's contents as the implementation of the command itself.

Once found, that command script is loaded and interpreted essentially like any other BeanShell script, executing with the arguments the caller provided, and its result, if any, is returned back to the calling script just as if a built-in, natively-implemented function had been called.

Because this mechanism is just a specific, conventionalized case of BeanShell's general scripting and classpath-loading capability, adding a custom command is possible by placing an appropriately named .bsh file in a location BeanShell's command search path checks, without needing to modify BeanShell's own core implementation at all.

This design reflects BeanShell's broader philosophy of using its own scripting capability to implement as much of its own functionality as practical, rather than hardcoding every convenience feature directly into the interpreter's compiled core - it's a form of the interpreter being extensible through the same mechanism it exposes to its users.