CL-LAUNCH(1)

📦 version 4.1.4.1, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu resolute, ubuntu stonking

💖 CL-LAUNCH 💖

okay so bestie, gather round, because this is the manual page for cl-launch — a shell wrapper for Common Lisp. it lives in section 1 of the manual, and it is genuinely iconic. let's get into it 💅

✨ SYNOPSIS ✨

like, four whole moods. pick your fighter:

cl [options] ´(lisp (form) to evaluate)´
    evaluate specified form, print the results followed by newline
    as in: cl -l sbcl -sp my-system-and-package ´(some form)´

cl [options] script-file arguments...
    run specified Lisp script, passing arguments, as in a script with
    #!/usr/bin/cl -sp my-system-and-package -E main

cl [options] [--execute] [options] [-- arguments...]
    run the specified software without generating a script (default)

cl [options] --output EXECUTABLE [options]
    generate an executable script or binary from the software specification

🎀 SPECIAL MODES 🎀

the little guys that don't do the whole build thing, they just vibe:

  • -h or -?, --help — display a short help message
  • -H, --more-help — show complete help (you may use a $PAGER, so go off)
  • -V, --version — display cl-launch version and configuration
  • -u FILE, --update FILE — update a cl-launch script to current version

🌸 SOFTWARE SPECIFICATION 🌸

this is where you tell cl-launch what software you actually want, no cap:

  • -w CODE, --wrap CODE — shell wrapper CODE to run in cl-launch
  • -l LISP..., --lisp LISP... — try use these LISP implementations
  • -m IMAGE, --image IMAGE — build from Lisp image IMAGE
  • -f FILE, --file FILE — include lisp FILE while building
  • -L FILE, --load FILE — load lisp FILE while building
  • -S X, --source-registry X — override source registry of asdf systems
  • -s SYSTEM, --system SYSTEM — load asdf SYSTEM while building
  • --load-system SYSTEM — same as above (buildapp compatibility)
  • -p PACKAGE, --package PACKAGE — change current package to PACKAGE
  • -sp SP, --system-package SP — combination of -s SP and -p SP
  • -e FORM, --eval FORM — evaluate FORM while building
  • --require MODULE — require MODULE while building
  • -DE N/F, --dispatched-entry N/F — if exec´ed as N, restart from (F argv)
  • -i FORM, --init FORM — evaluate FORM at restart
  • -ip FORM, --print FORM — evaluate and princ FORM at restart
  • -iw FORM, --write FORM — evaluate and write FORM at restart
  • -r FUNC, --restart FUNC — complete restart by calling (FUNC)
  • -E FUNC, --entry FUNC — complete restart by calling (FUNC argv)
  • -F FORM, --final FORM — evaluate FORM before dumping IMAGE
  • -I PATH, --include PATH — runtime PATH to cl-launch installation
  • +I, --no-include — disable cl-launch installation feature
  • -R, --rc — try read /etc/cl-launchrc, ~/.cl-launchrc
  • +R, --no-rc — skip /etc/cl-launchrc, ~/.cl-launchrc
  • -Q, --quicklisp — use quicklisp (see --more-help)
  • +Q, --no-quicklisp — do not use quicklisp
  • -b, --clbuild — use clbuild (see --more-help)
  • +b, --no-clbuild — do not use clbuild
  • -v, --verbose — be quite noisy while building
  • -q, --quiet — be quite quiet while building (default)

💅 OUTPUT OPTIONS 💅

where does the software go, bestie:

  • -x, -o !, --execute — run the specified software NOW (default)
  • -o FILE, --output FILE — create executable FILE
  • -d IMAGE, --dump IMAGE — dump IMAGE for faster startup
  • -X ... -- — (see more help) use #!/.../cl-launch as script interpreter
  • --, -- — end of arguments when using -x or -X

👑 INVOCATION OF CL-LAUNCH 👑

okay so here's the whole deal. cl-launch will evaluate Common Lisp code or create shell scripts or executable binaries that evaluate Common Lisp code. cl-launch follows the invocation conventions of both Unix script interpreters and Common Lisp implementations. it's giving bilingual, fr fr 🦋

A suggested short-hand name for cl-launch is cl (you may create a symlink if it isn´t included in your operating system´s cl-launch package). We´d like to homestead the path /usr/bin/cl while we can, so that script authors can reasonably expect a script to work when it starts with:

`#!/usr/bin/cl`

(See Simple cl-launch scripts below for caveats with #! scripts though.) Recent Linux kernels support a script interpreter itself being a script; BSD kernels don´t and require a small C program cl-shim to be compiled and installed as /usr/bin/cl to use cl-launch this way.

🫶 lowkey important: to work properly, cl-launch 4.1.4 depends on ASDF 3.1.2 or later, and on its portability layer UIOP, to manage compilation and image life cycle.

The software is specified as the evaluation of code in several phases; the distinction matters most for creating executable binaries, but understanding the evaluation model can avoid surprises in other cases too.

⭐ phase one: the Lisp image is initialized ⭐

In the first phase, the Lisp image is initialized:

  • optionally having your Lisp start from a Lisp IMAGE (option -I --image)
  • loading a small header of code that provides common cl-launch functionality
  • loading ASDF3. The cl-launch header will try hard to load ASDF 3.1.2 or later. If your implementation does not provide it via (require "asdf"), you can configure your implementation´s ASDF (if any) to find it. Or you can put it in your home, under ~/common-lip/asdf/ and cl-launch will find it. Or it may be installed in /usr/share/common-lisp/source/cl-asdf/ in which case cl-launch will also find it. Failing any of the above, cl-launch will be unable to proceed. 😭
  • optionally loading quicklisp http://beta.quicklisp.org/ (option -Q --quicklisp)

🌈 phase two: your software is built 🌈

In a second phase, your software is built, based on the following options, in order of appearance:

  • evaluating one or several FORMS (option -e --eval) in the current package. The series of forms is evaluated as by LOAD, in a context where the *package* has been set to the current package (see below explanations on packages).
  • compiling a FILE and load the fasl (option -L --load) Files are loaded with *package* bound to the current package (see below).
  • including a FILE, compiling it and loading the fasl (option -f --file) The contents of the FILE, which will have be included in the output script, will be compiled and the fasl loaded as if by option -L --load. The difference matters mostly when creating an output script, as opposed to executing the code immediately or dumping an image. Only one file may be specified this way. If a filename specified with -f --file is - (after stripping quotes), then the standard input is used. You may thus concatenate several files and feed them to cl-launch through a pipe. To use a file named -, pass the argument ./- (same trick as for cat and other Unix commands).
  • A script file, as specified by -X ... -- or by use of #! or by following options with an immediate filename that does not start with ( or -, counts as if preceded by --package cl-user --load and followed by --execute --
  • requiring an implementation-provided MODULE (option --require)
  • having ASDF3 compile and load a SYSTEM (option -s --system --load-system). Option -sp --system-package loads the SYSTEM like -s --system and also changes the current *package* like -p --package (see below on packages).
  • optionally having your Lisp DUMP an image to restart from (option -d --dump), and just before evaluating one or several FINAL forms (option -F --final). See section Dumping images.

If you are creating a shell script with option -o --output but without using option -d --dump, then these first two phases only happen when the script is invoked. If you are using option -d --dump, then these two phases happen immediately, and no compilation happen when invoking the output. Note that compiled files are cached, so that the compilation only happens the first time a file is loaded via --load of --system, or if the source file has been modified. This may cause slower startup the first time over. The cache is controlled by ASDF´s output-translations mechanism. See your ASDF manual regarding the configuration of this cache, which is typically under ~/.cache/common-lisp/

🧚 phase three: your software is run via UIOP:RESTORE-IMAGE 🧚

In a third phase, your software is run via UIOP:RESTORE-IMAGE. This happens immediately if using option -x --execute or calling cl-launch as a Unix interpreter on a script e.g. via #!; or it can happen later if you use option -o --output in combination with (or without) option -d --dump to dump an image (which gives you faster startup and single-file or double-file delivery, at the expense of disk space), at which point it happens when you invoke the executable output file:

  • Hooks from ASDF3´s UIOP:*IMAGE-RESTORE-HOOK* are called (in FIFO order).
  • a series of FORMS specified via options -i --init, -ip --print, -iw --write, stored as a text string, are read and evaluated in order of appearance, each in the context of the package that was current at the time it was requested. (Concatenated together with separating whitespace, these forms constitute the UIOP:*IMAGE-PRELUDE* as handled by RESTORE-IMAGE). Arguments that start with an open parenthesis are assumed to be FORMS that follow an implicit --print. Loading from a stream means you don´t have to worry about nasty read-time issues; forms will be read by the fully built Lisp image; however it also means that if you care a lot about the very last drop of startup delay when invoking a dumped image, you´ll only use option -r --restart or -E --entry and avoid using --init and its variants. Option -ip --print specifies FORMS such that the result of the last form will be printed as if by PRINC, followed by a newline. Option -iw --write is similar to --print, using WRITE instead of PRINC.
  • An optional FUNCTION provided option -r --restart or -E --entry is invoked after all init forms. If the function was provided with option -r --restart (compatible with earlier versions of cl-launch), it will be called with no argument. If it was provided with option -E --entry (compatible with buildapp), it will be called with one argument, being the list of arguments passed to the program, not including argv[0], which is available on most implementations via the function uiop:argv0 (available in ASDF 3.1.2 and later). Using either option, the argument may be a function name or a lambda expression, that is read from the current package (see below option -p --package and -sp --system-package). Only one restart or entry function may be specified; if multiple are provided, the last one provided overrides previous ones. If you want several functions to be called, you may DEFUN one that calls them and use it as a restart, or you may use multiple init forms as below. See also below options -DE --dispatch-entry, -sm --system-main, -Ds --dispatch-system that behave as if -E --entry had been specified among other things.

✨ part 1 done, bestie — more parts coming, don't go anywhere ✨

  • If you gave it neither a restart nor an entry function, the program just bounces with status 0 (success, we love a clean exit 💅). But if you did hand it a function, it sticks around until that function returns (if it ever does, no promises bestie 😭), and then exits with status 0 if and only if the primary return value of result is generalized boolean true — and status 1 if that value is NIL. Fr fr, go read the docs for UIOP:RESTORE-IMAGE for the details.

🎀 the current package situation

The current package can be controlled by option -p --package and its glow-up variant -sp --system-package, which also behaves like -s --system. Every single form you pass to --eval, --init, --print, --write, --final, --restart, --entry, etc., gets read in the current package. Same for files specified with -f --file --load — read in the current package. And "current" means: the package named by the latest -p --package or -sp --system-package option that comes before the option being processed, or cl-user if there wasn't one. 🌸

Heads up bestie 🙈 — multiple -i --init or -F --final forms may get evaluated consecutively after a package has been changed. And if one of those forms itself modifies the package, or some other syntax control mechanism like the reader gets involved, it may adversely affect later forms in the same category. It won't touch forms in other categories though (if those are even reached). Not me warning you twice 💀

✨ the derived options (they're just combos, iykyk)

The following derived options work as if by a combination of simpler options:

  • -sp --system-package — as mentioned above, combines --system and --package into one single option. Give it the argument SYSTEM and the system is loaded as if by --system SYSTEM, which creates a package SYSTEM that then becomes the current package. Two birds, one slay 🦋
  • -DE --dispatch-entry — if used, the next argument must follow the format NAME/ENTRY, where NAME is a name that the program may be invoked as (the basename of the uiop:argv0 argument), and ENTRY is a function to be invoked as if by --entry when that is the case. If the ENTRY is left out, function main in the current package is used. Support for -DE --dispatch-entry is delegated to a dispatch library, distributed with cl-launch but not part of cl-launch itself, by:
    1. registering a dependency on the dispatch library as if by --system cl-launch/dispatch (if not already),
    2. if neither --restart nor --entry was specified yet, registering a default entry function as if by --entry cl-launch/dispatch:dispatch-entry,
    3. registering a build-form that registers the dispatch entry as if by --eval ´(cl-launch/dispatch:register-name/entry "NAME/ENTRY" :PACKAGE)´ where PACKAGE is the current package.

See the documentation of said library for further details. 👑

  • -Ds --dispatch-system — if used with SYSTEM as its argument, it's as if option -s --system had been used with the same argument, followed by option -DE --dispatch-entry for the basename of the system (the last / (slash) separated component of the system name) and the function main in the package of the system — but without otherwise changing the current package.
  • -sm --system-main — if used with SYSTEM as its argument, it's as if option -s --system had been used with the same argument, followed by option -E --entry with the main function in the package of the system, but without otherwise changing the current package.

🌈 general note on cl-launch invocation

Options are processed from left to right. Usually, repeated options accumulate their effects, with the earlier instances taking effect before the latter instances. And in case of conflicting or redundant options, the latter override the former. Periodt. 💅

cl-launch defines a package cl-launch that exports the following symbol: compile-and-load-file. Runtime functionality formerly provided by cl-launch is now provided by UIOP, the portability layer provided by ASDF3. See below section cl-launch runtime API.

When the first non-recognized option is a filename, cl-launch will try to load this filename as a script, as if by --load, then execute it immediately as if by --execute --, with the rest of the command line passed as arguments. The file name may not start with the character - or a ( --- To use a file with one of these (or something unknown) as a first character, prepend ./ to the filename.

🚨 Bestie, listen — it is a security risk to let adversaries control the names of files passed to cl-launch or other commands. Do not do that. Fr fr.

When option --execute is specified, the specified software is executed. Command-line arguments may be given to software being executed by putting them after a special marker --, that ends cl-launch option processing.

When option --output FILE is used, code will be generated into the specified FILE. The output file itself will be created atomically from complete generated contents and may thus have the same pathname as the input file. The restart function and init forms will not be evaluated, but kept for when the output file is executed. ✨ If - (after quoting) is specified, then the standard output is used. If ! (after quoting) is specified, then option --execute is assumed.

When no --output file is specified, option --execute is implicitly assumed. The last --output or --execute option takes precedence over the previous ones.

If only one argument exists and it doesn't start with - then the argument is considered as if given to option -ip, to be evaluated and printed immediately.

💜 source-registry & lisp-selection vibes

The ASDF3 source-registry configuration can be overridden with option --source-registry SOURCE_REGISTRY. The provided configuration will take priority over anything provided by the environment or configuration files, though it may inherit from them as usual. See the ASDF3 manual about that. 📚

Options -l --lisp and -w --wrap may be used to control the way that a Common Lisp implementation is found when the software is run. Option -l --lisp specifies the list of implementations to try to use; the list is whitespace-separated, and consists in nicknames recognized by cl-launch. Option -w --wrap supplies arbitrary code to be evaluated by the shell wrapper, after it has read its configuration and defined its internal functions, but before it tries to find and run a Lisp implementation.

Such wrapper code is typically used to modify the variables that control the run-time behaviour of generated scripts, as documented below. Use of other internals of cl-launch is possible, but not supported, which means that it is your responsibility to keep a copy of the specific version of cl-launch with which your code works and to update your code if you later make an upgrade to an incompatible cl-launch. 🙈 For instance, --lisp "foo bar" is equivalent to --wrap ´LISPS="foo bar"´. See below the documentation section on Lisp implementation invocation.

🧚 include vs. no-include (the standalone debate)

Option --no-include specifies that cl-launch should generate a standalone script that includes the configuration, shell wrapper, Lisp header, and user-provided Lisp code (from --file). If you can rely on the presence of a recent Lisp implementation that provides ASDF, then the script is pretty much standalone indeed and may be moved around the filesystem and still used. However the size of the output will be the size of the user Lisp code plus about 36KiB.

Option --include PATH specifies that cl-launch should generate a very small script (typically under 1KiB) that when run will read the cl-launch shell wrapper and Lisp header from a specified installation directory PATH. Also, if option --include is used, and Lisp code is specified with --file and an absolute pathname starting with / as opposed to a relative pathname or to the standard input, then Lisp code will also be loaded from the specified location at runtime rather than embedded into the script at generation time. This option generates leaner scripts, but may not be applicable when the very same script is to used in a variety of situations that lack common coherent filesystem management. 🫶

Which of --include or --no-include is the default may depend on your cl-launch installation. The version of cl-launch distributed by the author uses --no-include by default, but the version of cl-launch available in your operating system distribution may rely on a well-managed include path (this is the case with debian for instance). You may query the configuration of an instance of cl-launch with option --version. ⭐

For instance, one may expect a debian version of cl-launch to use:

`/usr/share/common-lisp/source/cl-launch/`

as a system-managed include path. One may also expect that Lisp implementations managed by the system would come with cl-launch precompiled in Lisp images. Since cl-launch provides feature :cl-launch, and since the cl-launch Lisp header is conditionalized to not be read with this feature, this would make cl-launch startup faster, while still allowing non-system-managed Lisp implementations to run fine. 🌸

You may create an installation of cl-launch with such a command as:

cl-launch --include /usr/share/common-lisp/source/cl-launch \
        --lisp ´sbcl ccl clisp´ \
        --rc \
        --output /usr/bin/cl-launch -B install

You can use command -B install_bin if you only want to configure cl-launch (with a different default for --lisp but no --include, for instance), and command -B install_path if you only want to create support files. Note that the --backdoor option -B must come last in your invocation. 💅

🎀 rc files & quicklisp

Option +R --no-rc specifies that cl-launch should not try to read resource files /etc/cl-launchrc and ~/.cl-launchrc.

Option -R --rc specifies that cl-launch should try to read resource files /etc/cl-launchrc and ~/.cl-launchrc. These files are notably useful to define override the value of $LISP depending on $SOFTWARE_SYSTEM. A shell function system_preferred_lisps is provided so that your cl-launchrc might contain lines as follows:

system_preferred_lisps stumpwm cmucl sbcl clisp
system_preferred_lisps exscribe clisp cmucl sbcl
⚠️ Beware bestie — for the sake of parsing option --no-rc, the resource files are run after options are processed, and any overriding of internal variables will thus preempt user-specified options. A warning will be printed on the standard error output when such an override happens. Note that such overrides only happen at script-creation time. A script created by cl-launch will not try to read the cl-launch resource files. 💀

Option +Q --no-quicklisp specifies that cl-launch should not use quicklisp. Option -Q --quicklisp specifies that cl-launch should use quicklisp. Which is the default depends on your installation. The default default is +Q. Quicklisp is loaded from ~/quicklisp/setup.lisp if available, or else ~/.quicklisp/setup.lisp. 🍓

  • -b, --clbuild — tells cl-launch to lean on clbuild to find + invoke the Common Lisp implementation. team clbuild 💅
  • +b, --no-clbuild — tells cl-launch to NOT lean on clbuild for finding/invoking the implementation. classic.

Which one is the default? bestie, it depends on your installation. The default default is +b. iconic of it honestly.

okay so the files that cl-launch generates are made of several well-identifiable sections. Which means each section can lowkey be treated as its own separate piece of software, each one rocking its own intellectual-property regime (if any 💀). So if something goes sideways, you can still rescue the exact original code that came with option --file by stripping off the wrapper — it's all delimited by well-identified markers. Just search for the marker string "BEGINS HERE:". Everything after that? Not cl-launch. periodt.

You can do that automatically with the backdoor option -B extract_lisp_content. cl-launch itself uses this functionality implicitly whenever it embeds a file specified with option --file, so you can take a script that was previously generated by cl-launch and change the options it wraps the embedded Lisp code with to turn it into runnable software. 🦋

Alternatively, you can upgrade a previously generated script to use the current version of cl-launch while keeping its original wrapping options with option --update. In that case, software specification options get ignored. Output options still apply. Specifying - (after quoting) as the file to update means reading the contents to be read from the standard input. > heads up: this feature might not work with scripts generated by very early versions of the cl-launch utility. It should work with versions later than 1.47.

🌈 Supported Lisp implementations

The implementations supported by the current version of cl-launch are:

abcl allegro ccl clisp cmucl ecl gcl lispworks sbcl scl xcl

Also defined are aliases:

clozurecl gclcvs lisp openmcl

which are name variations for ccl, gcl, cmucl and ccl again respectively. (yes, ccl shows up twice, it's giving main character energy 👑)

Fully supported, including standalone executables:

  • sbcl: SBCL 1.2.2
  • clisp: GNU CLISP 2.49
  • ecl: ECL 13.5.1
  • cmucl: CMUCL 20D
  • ccl: ClozureCL 1.10
  • lispworks: LispWorks Professional 7.0.0 (no personal ed, banner)

Fully supported, but no standalone executables:

  • gcl (GCL 2.7): GCL 2.7.0 ansi mode (get a very recent git checkout)
  • allegro: Allegro 9.0 (also used to work with 5)
  • scl: Scieneer CL 1.3.9

Incomplete support:

  • abcl: ABCL 1.3.1 (no image dumping support, but you may use abcl-jar)
  • xcl: XCL 0.0.0.291 (cannot dump an image) (get a recent checkout)

GCL is only supported in ANSI mode. cl-launch does export GCL_ANSI=t in the hope that the gcl wrapper script does the right thing as it does in Debian. Also ASDF3 requires a very recent GCL 2.7. And ngl, GCL seems to not be very actively maintained anymore. 😭

There are some issues regarding standalone executables on CLISP. See below in the section regarding Standalone executables.

LispWorks requires the Professional Edition; the Personal Edition isn't supported as it won't let you either control the command line or dump images. Dumped images will print a banner, unless you dump a standalone executable. To dump an image, make sure you have a license file in your target directory and/or to .../lispworks/lib/7-0-0-0/config/lwlicense (or use a trampoline shell script to exec /path/to/lispworks "$@"), then create a build script with:

echo ´(hcl:save-image "lispworks-console" :environment nil)´ > si.lisp
lispworks-7-0-0-x86-linux -siteinit - -init - -build si.lisp

There is no standard name for a console-only variant of LispWorks; older versions of cl-launch assume a default lispworks; since cl-launch 4.1.2.1, lispworks-console is assumed instead, to avoid conflicts. You can control the name you use with the shell variable $LISPWORKS, or you can just leave lispworks-console in your path, and use a symlink, copy, shell alias or trivial wrapper script to enable your favorite shorter name lispworks, lw, lwcon, lw-console, etc. ✨

Similarly, a mlisp image for allegro can be created as follows:

alisp -e ´(progn
           (build-lisp-image "sys:mlisp.dxl"
            :case-mode :case-sensitive-lower
            :include-ide nil :restart-app-function nil)
           (when (probe-file "sys:mlisp") (delete-file "sys:mlisp"))
           (sys:copy-file "sys:alisp" "sys:mlisp"))´

Additionally, cl-launch supports the use of clbuild as a wrapper to invoke the Lisp implementation, with the --clbuild option.

🐚 Supported shells

cl-launch was tested with all of posh 0.4.7, bash 2.05, bash 3.1, zsh 4.3.2, dash 0.5.3 and busybox 1.01 ash. a whole squad fr fr 🫶

💖 Lisp implementation invocation

When a cl-launch generated script is invoked, the cl-launch shell wrapper will try to execute the Lisp code with the first Common Lisp implementation it finds in a given list, which can be specified through option --lisp. The runtime behaviour of the cl-launch shell wrapper is very configurable through a series of environment variables. These variables can be controlled by the user by exporting them in his environment, or they can be restricted at the time of script generation by using cl-launch option --wrap.

If variable LISP is defined, the shell wrapper will first try the implementation named by variable LISP. If that fails, it will try the list of implementations provided at script generation time. The list of implementations generated will be the argument to option --lisp if specified. Otherwise, cl-launch will supply its default value. This default value for the current instance of cl-launch is:

sbcl ccl clisp abcl allegro lispworks scl cmucl ecl mkcl gcl xcl

This LISP selection only happens at system preparation time. If you dump an image then the script will always use the Lisp implementation for which an image was dumped. If you don't, then the user may override the implementation.

note that these are nicknames built into the cl-launch shell wrapper, and not necessarily names of actual binary. iykyk.

You may control the mapping of implementation nickname to actual binary pathname to call with an environment variable. For a given implementation nickname, the environment variable will be the capitalization of the given nickname. Hence, variable $SBCL controls where to look for the sbcl implementation, and variable $CMUCL controls where to look for the cmucl implementation. If a binary is found with a matching pathname (using the standard unix $PATH as required), then said implementation will be used, using proper command line options, that may be overridden with an environment variable similar to the previous but with _OPTIONS appended to its name. Hence, $CMUCL_OPTIONS for cmucl, $CLISP_OPTIONS for clisp, etc. Sensible defaults are provided for each implementation, so as to execute the software in non-interactive mode, with debugger disabled, without reading user-specific configuration files, etc. 💅

If you want to insist on using a given implementation with given options, you may use option --lisp and --wrap, as follows:

--lisp ´sbcl clisp´ --wrap ´
    LISP= # do not allow the user to specify his implementation
    SBCL=/usr/bin/sbcl # not any experimental thing by the user
    SBCL_OPTIONS="--noinform --sysinit /dev/null --userinit /dev/null \
    --disable-debugger" # predictable Lisp state
    CLISP=/usr/bin/clisp # fall back on machines that lack SBCL
    CLISP_OPTIONS=" -norc --quiet --quiet"
    # configure ASDF:
    CL_SOURCE_REGISTRY=/usr/local/share/common-lisp/source//:
    # assuming precompiled fasls there:
    ASDF_OUTPUT_TRANSLATIONS=/my/cl/src:/my/fasl/cache:
    ´

If you dump an image, you need not unset the LISP variable, but you might still want to override any user-specified SBCL and SBCL_OPTIONS (or corresponding variables for your selected implementation) from what the user may specify.

Note that you can use option --wrap "$(cat your_script)" to embed into your program a full fledged script from a file. Your script may do arbitrary computations before the shell wrapper is run. It may make some consistency checks and abort before to run Lisp. Or it may analyze invocation arguments and make according adjustments to Lisp implementation options. This can be useful for setting options that cannot be set from the Lisp code, such the path to a runtime image, interactive or non-interactive execution, size of heaps, locale settings for source file encoding, etc. 🌸

Reading the source code of cl-launch can be completely crazy. You may have great fun understanding why things are how they are and adding features without breaking anything! 😭 However, adding support for a new CL implementation should be straightforward enough: just search the sources for clisp or sbcl and mimic what I did for them. Be sure to send me what will get your favorite Lisp flavor of the month rolling. 🎀

🧚 Limited clbuild support

cl-launch 2.12 and later support using clbuild as a wrapper to configure your Lisp implementation, with option --clbuild (which can be disabled with option --no-clbuild if it was enabled by default in your cl-launch installation).

note that when you use clbuild, you can no longer override implementation options with say SBCL_OPTIONS, as clbuild takes care of the options for you. Any implementation banner will not be removed unless you instruct clbuild to do so. Also, you cannot use clbuild with a non-executable image different from clbuild's, which precludes image dumping with cmucl or allegro (allegro could probably be updated, but I don't have a recent licence to test and develop).

clbuild support is not fully tested at this point. Please report any bug. 🐛

💖 Simple cl-launch scripts 💖

Okay bestie, listen — sometimes you just don't want a whole script-generation step. Like, if you're gonna be editing and shipping this script constantly and you're only running one instance at a time on a given machine, startup time is literally not the vibe. So you can just let cl-launch itself act as the interpreter, like this (strip the leading spaces, bestie):

#!/path/to/cl-launch ...options...

So for example you could write a script that looks like this (again, leading spaces stripped):

#!/usr/bin/cl --entry main
(defun main (argv)
  (format t "Hello, World!~%~S~%" argv))

On a recent Linux kernel, those options can totally include spaces, parentheses, whatever — you just gotta quote them like you would in a shell script. And here's a pro move: put -X as your very first option and -- as your last, and the script will still work even if its own name starts with a ( or a -, plus it stays compatible with older versions of cl-launch. Iconic.

⚠️ But heads up: Darwin (MacOS X) and other BSD kernels — and old Linux kernels — do not like the #! interpreter to itself be interpreted. On those kernels, your sysadmin has to compile and install a little shim written in C, cl-shim.c, that handles the script invocation properly. No cap.

Most kernels also have restrictions on how they handle arguments to a #! script that stop you from, say, using /usr/bin/env as a trampoline. But there's a fully portable solution, where that ":" ; is doing the work so the script stays valid bilingual shell and Lisp code:

#!/bin/sh
":" ; exec cl-launch -X -sp my-package -E main -- "$0" ${1+"$@"} || exit

(Okay real talk: "$@" instead of ${1+"$@"} should work just fine too, unless you're running some antique shell. 💀)

And if you don't actually need Lisp code loaded from your script — like, everything happens in the build specification — then you can just use a plain #!/bin/sh script and do:

exec /path/to/cl-launch -x ... -- "$@".

Also! In case you can't rely on cl-launch living at a fixed path, or your shell/kernel combo doesn't support using cl-launch as a script interpreter, you can start your script with these lines instead:

#!/bin/sh
":" ; exec cl-launch -X -- "$0" "$@" || exit
(format t "It works!~%")
🌸 One more kernel lore drop: a mainline Linux kernel only supports the recursive #! implicit in #!/usr/bin/cl-launch since 2.6.27.9.

📦 Dumping images 📦

You can dump an image (for static compilation and fast startup, the dream) with the option --dump IMAGE, where IMAGE is the path where the image gets dumped.

If you use the option --include PATH, then the image will be loaded back from that specified directory instead of the directory where you dumped it. This is so useful if you're preparing a script to be installed somewhere else — maybe even on another computer. 🧚

This option is currently supported on all CL implementations available with cl-launch. Slay.

⚠️ Limitations, bestie, listen up: - LispWorks will print a banner on standard output, unless you use the standalone executable option below. - ECL will not be able to dump an image when running from a previously dumped image (with --image). Why? Because of the link model of ECL: you'd need to be able to locate which object files were used in linking the original image, keep track of those files, and prepend the list of them to the object files linked into the dump. This isn't conceptually impossible and patches are welcome. But we hope to support that someday with a real build system that does it for you, such as XCVB.

👑 Standalone executables 👑

You can create standalone executables with the option --dump '!' (or by giving a --dump argument identical to the --output argument).

This option is currently only supported with SBCL, ECL, CLISP, CMUCL, CCL and LispWorks Professional. And also CLISP has the issues below. 🙈

💀 CLISP standalone executables will react magically if invoked with options such as --clisp-help or --clisp-x '(sys::main-loop)'. That's a pretty far-fetched thing to hit by mistake, and the CLISP maintainers consider it a feature (I don't). Don't use such executables as setuid, and don't let untrusted users control arguments given to such executables that are run with extra privileges. This one is serious, fr fr.

✨ cl-launch runtime API ✨

cl-launch provides the following Lisp functions:

Function cl-launch:compile-and-load-file takes as an argument a source pathname designator, and keyword arguments force-recompile (default NIL) and verbose (default NIL). It will arrange to compile the specified source file if it is explicitly requested, or if the file doesn't exist, or if the fasl is not up-to-date. It will compile and load with the specified verbosity. It will take use uiop:compile-file-pathname* to determine the fasl pathname.

The following variables and functions previously provided by cl-launch have the following replacement from ASDF and UIOP:

  • Variable cl-launch:*arguments* is replaced by uiop:*command-line-arguments*.
  • Function cl-launch:getenv is replaced by uiop:getenv.
  • Function cl-launch:load-system is replaced by asdf:load-system.
  • Function cl-launch:quit is replaced by uiop:quit (beware: the lambda-list is slightly different).

Additionally, environment variables CL_LAUNCH_PID and CL_LAUNCH_FILE will be set to the process ID and the script invocation filename respectively. 🎀

🗣️ Verbose output mode 🗣️

If the shell variable CL_LAUNCH_VERBOSE is exported and non-nil, then cl-launch and the scripts it generates will produce an abundance of output — displaying such things as the Lisp invocation command, compiling and loading files with :verbose t and :print t, etc. This is only useful for debugging cl-launch and/or your build process. Option --verbose sets this variable, whereas option --quiet resets it.

🛠️ Makefile examples 🛠️

### Automatically download of the current version of cl-launch if not present
cl-launch.sh:
        wget -O cl-launch.sh http://fare.tunes.org/files/cl-launch/cl-launch.sh
        chmod a+x cl-launch.sh

### Making a shell script executable from a simple Lisp file named foo.lisp
foo.sh: cl-launch.sh foo.lisp
        ./cl-launch.sh --output foo.sh --file foo.lisp

### A more complex example using all options.
run-foo.sh: cl-launch.sh preamble.lisp
        ./cl-launch.sh --output run-foo.sh \
        --file preamble.lisp --system foo \
        --init "(foo:main uiop:*command-line-arguments*)" \
        --source-registry ${PREFIX}/cl-foo/systems: \
        --lisp "ccl sbcl" --wrap ´SBCL=/usr/local/bin/sbcl-no-unicode´ \
        --no-include

### An example with horrible nested makefile, shell and Lisp quoting
hello:
        opera=wORlD ; ./cl-launch.sh --execute --init \
        "(format t \"~25R~A~A~%\" 6873049 #\\space ´$$opera)"

🫶 Caveat Lispor 🫶

cl-launch begins evaluation of your Lisp software in the cl-user package, or whichever package you specify. By the time your initialization forms are evaluated, the package may or may not have changed, depending on the fine-grained semantics of load. Be sure to use in-package if these things matter. And if you change the readtable? Even weirder things may happen. 😭

There are lots of ways of making mistakes by improperly quoting things when you write shell commands. cl-launch does the right thing, but you still must be careful with the nested quoting mechanisms of make, shell, and Lisp.

Here's a simple example use of cl-launch to quickly compare the result of a same computation on a variety of systems:

for l in sbcl cmucl clisp gcl ccl ; do
  ./cl-launch.sh --lisp $l --execute --init \
    ´(format t "´$l´ ~A~%" most-positive-fixnum)´ ; done

Internally, cl-launch includes many self-test functions. You may for instance try (from a directory where it may create junk):

./cl-launch.sh -l ´sbcl cmucl clisp gclcvs´ -B tests

Share and Enjoy! 🌈

See our web page on:

<http://www.cliki.net/cl-launch>

💡 Note: if this help is too long for you, you may scroll back, or use: cl --more-help | less

And that's a wrap, bestie! 💖 This whole iconic manual page is brought to you by Francois-Rene Rideau, dated July 2015, and it lives in section CL-LAUNCH(1) of your friendly neighbourhood man pages. Go forth and launch some Lisp, you absolute main character. 👑✨

📦 where this page comes from