cl-launch is a unix utility to make your Lisp software easily invokable from the shell command-line.

License: MIT

Source repository: git clone git://
Or with the proper account, git clone ssh://

View the repository:

Download it:

cl-launch will help you invoke your Lisp software from the Unix command-line or as a #! script. We encourage you to install cl-launch 4.0.6 or later and write scripts using #!/usr/bin/cl. A trivial shim written in C is required for it to work on BSD kernels. It is a self-contained shell-script by Fare Rideau that will abstract away the details of the underlying Lisp implementation by generating the proper Lisp and shell code. Extensive automated testing ensures that it works in thousands of valid combined operation modes, Lisp and shell implementations.


#!/usr/bin/cl -sp lisp-stripper -E main
(defun main (argv)
  (if argv
      (map () 'print-loc-count argv)
      (print-loc-count *standard-input*)))

Or to compare evaluation of a form on all supported implementations:

for l in sbcl ccl clisp cmucl ecl abcl scl allegro lispworks gcl xcl ; do
   cl-launch -l $l -i '(format t "'$l': ~S~%" `#5(1 ,@`(2 3)))' \
   2>&1 | grep "^$l:" # LW, GCL are verbose

Here follows the output of /usr/bin/cl --more-help: 4.0.6 -- shell wrapper generator for Common Lisp software

	cl '(lisp (form) to evaluate)'
	    evaluate specified Lisp form, print the results followed by newline
	cl [options] script-file arguments...
	    load specified Lisp script, passing arguments
	cl [options] --execute [options] [-- arguments...]
	    run the specified software without generating a script (default)
	cl [options] --output SCRIPT [options]
	    generate a runnable shell script FILE from a software specification
	cl [options] --update FILE [options]
	    same as above, but reuse software specification from previous FILE
	cl [ --version | --help | --more-help ]
	    display information (might be long, you may pipe it into a pager)

Special modes:
 -h  or  -?	--help		 display a short help message
 -H		--more-help	 display a longer help message
 -V		--version	 display cl-launch version and configuration
 -u FILE	--update FILE	 update a cl-launch script to current version

Software specification:
 -w CODE	--wrap CODE          shell wrapper CODE to run in cl-launch
 -l LISP...	--lisp LISP...	     try use these LISP implementation(s)
 -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
 -r FUNC	--restart FUNC       restart from build by calling (FUNC)
 -E FUNC	--entry	FUNC	     restart from build by calling (FUNC argv)
 -i FORM	--init FORM	     evaluate FORM after restart
 -ip FORM	--print FORM	     evaluate and princ FORM after restart
 -iw FORM	--write FORM	     evaluate and write FORM after restart
 -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:
 -x      -o !   --execute	     run the thing 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


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.

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:
(See SIMPLE CL-LAUNCH SCRIPTS below for caveats with #! scripts though.)

To work properly, cl-launch 4.0.4 depends on ASDF 3.0.1 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.

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 to load ASDF 3.0.1 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

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 '-' (without the 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 './-'.
* 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)
  also changes the package at runtime, see option -p --package below.
* 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/

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; 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
* 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. (Concatenate 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.
  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.
* If neither restart nor entry function is provided, the program will exit with
  status 0 (success). If a function was provided, the program will exit after
  the function returns (if it returns), with status 0 if and only if the
  primary return value of result is generalized boolean true, and with status 1
  if this value is NIL. See documentation for UIOP:RESTORE-IMAGE for details.

The current package can be controlled by option -p --package and its variant
-sp --system-package that also behaves like -s --system. All forms passed to
--eval, --init, --print, --write, --final, --restart, --entry, etc., are read
in the current package. Files specified with -f --file --load are read in the
current package. Current means the package specified by the latest option -p
--package or -sp --system-package preceding the option being processed, or
cl-user if there was none. Note that multiple -i --init or -F --final forms
may be evaluated consecutively after a package has been changed, and that
if one of these form itself modifies the package, or some other syntax control
mechanism such as the reader, it may adversely affect later forms in the same
category, but not those in other categories (if reached).

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 latter instances. In case of conflicting or redundant
options, the latter override the former.

cl-launch defines a package :cl-launch that exports the following symbol:
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 a '-' or a '(' (without quotes).
To use a file with one of these (or something unknown) as a first character,
prepend './' to the filename. Note that it is a security risk to let
adversaries control the names of files passed to cl-launch or other commands.

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 '-' (without quotes) is specified, then the standard output is used.
If '!' (without quotes) 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.

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'.

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 28KiB.

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
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 the 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.

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 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 that for the sake of parsing option --no-rc, the resource files are run
*after* options are processed, and that 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

Option -b --clbuild specifies that cl-launch should rely on clbuild to
find and invoke the Common Lisp implementation.
Option +b --no-clbuild specifies that cl-launch should not rely on clbuild
to find and invoke the Common Lisp implementation.
Which is the default depends on your installation. The default default is +b.

Files generated by cl-launch are made of several well-identifiable sections.
These sections may thus be considered as distinct software, each available
under its own regime of intellectual property (if any). In case of an accident,
you may still retrieve the exact original code provided with option --file
by stripping the wrapper, as delimited by well-identified markers.
Search for the marker string "BEGINS HERE:". Every after it is not cl-launch.
This can be done automatically with backdoor option -B extract_lisp_content.
cl-launch uses this functionality implicitly when embedding a file specified
with the option --file, so that you may process a script previously generated
by cl-launch and change the options with which it wraps the embedded Lisp code
into runnable software.

As an alternative, you may also upgrade a previously generated script to use
the current version of cl-launch while preserving its original wrapping options
with option --update. In this case, software specification options are ignored.
Output options still apply. Specifying '-' (without quotes) as the file to
update means to read the contents to be read from the standard input.
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.


The implementations supported by 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.

Fully supported, including standalone executables:
  sbcl:  SBCL 1.1.14
  clisp:  GNU CLISP 2.49
  ecl:  ECL 13.5.1
  cmucl:  CMUCL 20D
  ccl:  ClozureCL 1.10
  lispworks:  LispWorks Professional 6.1.0  (no personal ed, banner)

Fully supported, but no standalone executables:
  gcl (GCL 2.7):  GCL 2.7.0 ansi mode  (get a recent release)
  allegro:  Allegro 9.0  (also used to work with 5)
  scl:  Scieneer CL 1.3.9

Incomplete support:
  abcl:  ABCL 1.2.1 (no image dumping support at this time)
  xcl:  XCL (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 ASDF requires a very recent GCL 2.7 for ASDF3 support.
Note that 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. Personal edition isn't supported
as it won't let you 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
(or use a trampoline shell script to exec /path/to/lispworks "$@"),
create a build script with
       echo '(hcl:save-image "lispworks" :environment nil)' > si.lisp
       lispworks-6-1-0-x86-linux -siteinit - -init - -build si.lisp
LispWorks also requires that you have ASDF 3.1.2 or later;
make sure you have it installed and configured in your source registry.

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.


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.


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 cmucl ecl abcl scl allegro lispworks 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. 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 a sbcl implementation, and variable $CMUCL controls where to look
for a 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 overriden 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"
CL_SOURCE_REGISTRY=/usr/local/share/common-lisp/source//: # configure ASDF
ASDF_OUTPUT_TRANSLATIONS=/my/cl/src:/my/fasl/cache: # assuming precompiled fasls there

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.


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

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


In simple cases, you may create a Common Lisp shell script with cl-launch
without a script generation step, just because you'll spend a lot of time
editing the script and distributing it, and little time waiting for script
startup time anyway. This notably is a good idea if you're not spawning many
instances of the same version of a script on a given computer. If that's
what you want, you may use cl-launch as a script interpret the following way
(stripping leading spaces):
  #!/path/to/cl-launch ...options...
For instance, you may write the following script (stripping leading spaces):
  #!/usr/bin/cl --entry main
  (defun main (argv)
    (format t "Hello, World!~%~S~%" argv))
The options must be quoted as in a shell script.
Also, using -X as your very first option and -- as your last will ensure that
the script works even if its name starts with a '(' or a '-', in addition
to working with older versions of cl-launch.

Note however that Darwin and possibly other BSD kernels or old Linux kernels
don't like the #! interpreter to itself be interpreted. On Darwin (and maybe
other BSD systems?), you use /usr/bin/env as a trampoline, as in
  #!/usr/bin/env /usr/bin/cl -sp my-package -E main
  #!/usr/bin/env cl-launch -sp my-package -E main
However, that recipe might not work on older Linuxor BSD kernels, that
don't properly space-separate the first-line arguments in a #! scripts but
provide them all (if any, after stripping the first line to 127 characters)
as a single argument in first position (cl-launch itself knows to work around
this limitation peculiarity, but can only do so after it is itself launched).
The full portable solution is thus as follows, where the ":" ; ensures that
the script should remain valid bilingual shell and Lisp code:
  ":" ; exec cl-launch -X -sp my-package -E main -- "$0" ${1+"$@"} || exit
(Actually "$@" instead of ${1+"$@"} should work just fine,
unless you have an antique shell.)

Note that if you don't need Lisp code to be loaded from your script,
with everything happening in the build specification, then you may instead
use a simple #!/bin/sh shell script from which you
   exec /path/to/cl-launch -x ... -- "$@".

Also, in case you can't rely on cl-launch being at a fixed path, or if your
shell and/or kernel combination doesn't support using cl-launch as a script
interpreter, then you may instead start your script with the following lines
(stripping leading spaces):
  ":" ; exec cl-launch -X -- "$0" "$@" || exit
  (format t "It works!~%")
Note that a mainline Linux kernel only supports the recursive #!
implicit in #!/usr/bin/cl-launch since


You can dump an image (for static compilation and fast startup) with option
--dump IMAGE where IMAGE specifies the path where the image will be dumped.

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

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

As a limitation, LispWorks will print a banner on standard output,
unless you use the standalone executable option below.

As another limitation, ECL will not be able to dump an image when running
from a previously dumped image (with --image). This is because with the
link model of ECL, you'll need to be able to locate which object files were
used in linking the original image, keep track of these files, and prepend
the list of them to to the object files linked into the dump. Doing this
is unhappily out of the scope of cl-launch;
however, we hope to support that someday with a real build system such as XCVB.


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.
Moreover 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.


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 previous 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.


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,
display 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.


When you develop programs that you will use with cl-launch, you may as well use
cl-launch during development, and benefit from its functionality.

To this end, you may explicitly include the cl-launch Lisp header from your
Lisp source code or from the Lisp initialization file for your favorite
implementation  (~/.sbclrc, ~/.cmucl-init, ~/.clisprc, etc.):
  #-cl-launch (load "/usr/share/common-lisp/source/cl-launch/launcher.lisp")
If cl-launch is not installed at a fixed system location, you may create
a copy in your own directory with such a command as
	cl-launch -B print_lisp_launcher > ~/src/cl-launch/launcher.lisp

Alternatively, you may include cl-launch itself instead of an extracted header,
if only you tell your Lisp reader consider #! as introducing a line comment:

    (set-dispatch-macro-character #\# #\!
      #'(lambda (stream char arg)
	   (declare (ignore char arg)) (values (read-line stream))))
    #-cl-launch (load "/path/to/")

Finally, if you use cl-launch from debian, or it was otherwise installed with
	cl-launch -B install
or if you create the asd in addition to the header and declare it to asdf
	cl-launch -B print_cl_launch_asd > ~/src/cl-launch/cl-launch.asd
then if your installed cl-launch.asd is properly symlinked from a directory
in your asdf:*central-registry*, you may just have your software depend on
the system :cl-launch
	(asdf:load-system :cl-launch)
which in some implementations (sbcl) can be simplified into
	(require :cl-launch)
You may also declare in the asdf:defsystem for your software that it
	:depends-on (:cl-launch ...)


### Automatically download of the current version of cl-launch if not present
	wget -O
	chmod a+x

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

### A more complex example using all options. preamble.lisp
	./ --output --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' \

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


cl-launch begins evaluation of your Lisp software in the CL-USER package.
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.

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 is 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
    ./ --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)
	./ -l 'sbcl cmucl clisp gclcvs' -B tests

Share and Enjoy!

See our web page on

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