Provided by: cl-launch_4.1.4-1.1_all bug


       cl-launch - shell wrapper for Common Lisp


       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

       -h  or  -?  --help           display a short help message
       -H          --more-help      show complete help (you may use a $PAGER)
       -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 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

       -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

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

       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.

       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 (option -Q --quicklisp)

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

       •   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

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

       •   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).

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

       •   As mentioned above, option -sp --system-package combines --system and --package in one
           option, so that given the argument SYSTEM, the system is  loaded  as  if  by  --system
           SYSTEM that creates a package SYSTEM that then becomes the current package.

       •   If  option -DE --dispatch-entry is used, then 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 current package is  used.
           Support   for  option  -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.

       •   If option -Ds --dispatch-system is used with SYSTEM as  its  argument,  it  is  as  if
           option  -s  --system  had  been  used  with  the same argument, followed by option -DE
           --dispatch-entry for the basename of the system (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.

       •   If option -sm --system-main is used with SYSTEM as its argument, it is 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

       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

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

       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 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:


       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.

       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  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 ~/.quicklisp/setup.lisp.

       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:". Everything 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

       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  -  (after quoting) 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.

Supported Lisp implementations

       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.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 (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. 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; 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 "$@"), create a build  script

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

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. 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:
               # 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.

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

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

Simple cl-launch scripts

       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))

       On a recent Linux kernel, the options may include spaces, parentheses, etc., provided they
       are 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 (MacOS X) and other BSD kernels or old Linux kernels  don´t  like
       the #! interpreter to itself be interpreted. On these operating system kernels, the system
       administrator must compile and install a small shim written in  C,  cl-shim.c,  that  will
       handle the proper script invocation.

       Most  kernels  have restrictions on how they handle arguments to a #! script, that prevent
       e.g. using /usr/bin/env as a trampoline; however, you may use the fully portable  solution
       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

       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:

           ":" ; 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

Dumping images

       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 of the link model of ECL, whereby
       you´d 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. This  is  not  conceptually  impossible  and  patches  are  welcome.
       However,  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. 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 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

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

Makefile examples

       ### 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)"

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. If you change the readtable, even weirder things may

       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:

               cl --more-help | less