q foo.q

(The script name can also be followed by other parameters which are passed to the script and can be accessed through the built-in ARGS variable of the interpreter.)

You can also execute compiler and interpreter separately, like so:

        qc foo.q
        q q.out

The compiler will then compile the source script foo.q to a ``bytecode'' file q.out which will then be loaded by the interpreter. Note that if you run a source script through the interpreter, then the compilation step is handled automatically (using a unique temporary code file name in order to prevent clashes between different interpreter processes which happen to be started simultaneously in the same directory). Furthermore, the bytecode file is removed automatically as soon as it has been loaded by the interpreter.

Script and code files are searched for on the ``Q library path'' which usually defaults to something like

        .:/usr/share/q/lib:/usr/lib/q

You can override this default by setting the QPATH environment variable or by using the -p command line option.

Both compiler and interpreter can also be invoked without arguments, in which case only the built-in functions and any definitions in the script prelude.q are loaded. Note that the prelude script, which is searched for on the library path as well, is always included as the first file in a compilation, which makes it possible to extend the built-in functions of the interpreter with your own ``preloaded'' definitions. The distributed prelude script simply includes all scripts in Q's standard library. The automatic inclusion of the prelude script can also be suppressed with the --no-prelude compiler option.

The interpreter also provides an interface to ``extern'' functions written in C, which are loaded (at runtime, if possible) from ``external'' modules. Modules are searched for on the library path as usual, but also in other system-dependent locations where ``shared libraries'' are looked for. To create an external module from a collection of C or object files, you can invoke the qcc program with these files as arguments. The first filename usually specifies the basename of the module to build, but this can be overridden with the -o option. Any extra options for compiler and linker should be placed at the end of the parameter list, after the -- option which tells qcc to end its option parsing and pass the remaining options on to the compiler and, for options following the --link option, the linker.

If your system does not support dynamic loading of modules, or if you want to debug a module, you have to create a custom interpreter which has the relevant modules statically linked in. The qld program creates such a ``preloaded'' executable which has the given ``dlopen'' modules linked into the interpreter, using libtool in link mode. The given options are simply passed on to libtool which does all the real work (see the libtool info manual for details).

A closer description of the options of the qcc and qld programs and the C interface in general can be found in the Q info file.

Last but not least, the qcwrap program creates a C wrapper from a Q script, which can then be compiled to a self-contained, binary executable. This is described in more detail in the Q info file.