License: LLGPL
Source repository: http://common-lisp.net/project/xcvb/git/cl-launch.git
Download: http://common-lisp.net/project/xcvb/cl-launch/
cl-launch will help you invoke your Lisp software from the Unix command-line. It is a self-contained shell-script 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.
Currently supported Lisp implementations:
Full support (including standalone programs): sbcl 1.0.22, clisp 2.48, clozurecl 1.2, ecl 0.9.6
Supporting everything but standalone programs: cmucl 19b, allegro 5.0, gcl 2.7.
Partial support: gcl 2.6 (no asdf), lispworks 5.1 pro (with limitations).
Here follows the output of /usr/bin/cl-launch.sh --more-help:
cl-launch.sh 2.15 -- shell wrapper generator for Common Lisp softwareUsage: cl-launch '(lisp (form) to evaluate)' evaluate specified Lisp form, print the results followed by newline cl-launch --execute [...] [-- arguments...] run the specified software without generating a script (default) cl-launch --output SCRIPT [--file LISP_FILE] [--init LISP_FORM] [...] generate a runnable shell script FILE from a software specification cl-launch --update FILE [...] same as above, but reuse software specification from previous FILE cl-launch [ --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: -m IMAGE --image IMAGE Load Lisp image IMAGE -f FILE --file FILE FILE to be embedded or loaded -s SYSTEM --system SYSTEM asdf SYSTEM to be loaded -r FUNC --restart restart FUNC to funcall before initializations -i FORM --init FORM initialization FORM to evaluate after loading -ip FORM --print FORM evaluate and princ FORM after loading -iw FORM --write FORM evaluate and write FORM after loading -p PATH --path PATH register asdf systems search PATH -pc --path-current register current directory to asdf (default) +p --no-path do not register any asdf system PATH -l LISP... --lisp LISP... specify list of supported LISP implementations -w CODE --wrap CODE specify shell CODE to run in the wrapper -I PATH --include PATH specify runtime PATH to cl-launch installation +I --no-include disable cl-launch installation feature -R --rc try read /etc/cl-launchrc and ~/.cl-launchrc +R --no-rc skip /etc/cl-launchrc and ~/.cl-launchrc -b --clbuild use clbuild (see limitations in documentation) +b --no-clbuild do not use clbuild -v --verbose be very noisy while building software -q --quiet be quiet while building software (default)
Output options: -x -o ! --execute no file creation, run the thing NOW (default) -o FILE --output FILE specify FILE name of output script -d DUMP --dump DUMP dump an image of the world for faster startup -X ... -- (see more help) use #!/path/to/cl-launch as script interpreter -- -- end of cl-launch arguments when using -x or -X
INVOCATION OF CL-LAUNCH
CL-Launch will create a shell script that, when invoked, will evaluate the specified Lisp software with an appropriate Common Lisp implementation.
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).
The software is specified as the execution, in this order, of: * optionally having your Lisp start from a Lisp IMAGE (option --image) * loading a small header of code that provides common cl-launch functionality * optionally loading the contents of a FILE (option --file) * optionally having ASDF load a SYSTEM (option --system) * optionally having your Lisp DUMP an image to restart from (option --dump) * optionally having your Lisp execute a RESTART function (option --restart) * optionally evaluating a series of initialization FORMS (option --init)
General note on cl-launch invocation: options are processed from left to right; in case of conflicting or redundant options, the latter override the former.
The cl-launch Lisp header manages compilation of Lisp code into a fasl cache and provides uniform access to the invocation context. It defines a package :cl-launch that exports the following symbols: *arguments* getenv quit load-system compile-and-load-file compile-file-pathname* apply-pathname-translations *output-pathname-translations* apply-output-pathname-translations See below section 'CL-LAUNCH RUNTIME API'.
The cl-launch header will try to load ASDF. It will first try to (require ...) it from your Lisp implementation, then will try a path provided through environment variable $ASDF_PATH if available, then it will look in your home directory under ~src/asdf/asdf.lisp and finally it will search for the default common-lisp-controller installation of it in /usr/share/common-lisp/source/asdf/asdf.lisp or /usr/share/common-lisp/source/cl-asdf/asdf.lisp If asdf is not found, cl-launch will proceed but you won't be able to use it and the --system option will be unavailable.
Only one input files may be specified with option --file. Now, if the specified filename 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. Or you may write Lisp code that loads the files you need in order.
Only one system may be specified with option --system, because the right thing to do if your software depends upon multiple systems is to write a system definition that :depends-on several other systems. It may still be useful to combine options --file and --system, since you may want to prepare your Lisp system with proper settings and proclamations before you load your system.
You may specify that a snapshot image of the Lisp world be dumped at this point with option --dump. Execution of the program will consist in restarting the Lisp implementation from that dumped image. See section DUMPING IMAGES.
You may optionally specify a restart function with option --restart, to be called every time the software is invoked. If you are dumping an image, this function will be called right after execution resumes from the dumped image. If you are not dumping an image, it will merely be executed after loading the system from source or fasl. Only one restart function may be specified with option --restart. 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 init forms below.
Several instances of option --init FORMS may specify as many series of forms that will be read and evaluated sequentially as top-level forms, as loaded from a string stream after the rest of the software has been loaded. Loading from a stream means you don't have to worry about packages and other nasty read-time issues; 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 be using option --restart only and avoiding --init. Option --print (or -ip) specifies FORMS where the result of the last form is to be printed as if by PRINC, followed by a newline. Option --write (or -iw) is similar to --print, using WRITE instead of PRINC.
When the various side effects from software invocation happen depend on how cl-launch is invoked. For the purpose of side effects, software invocation may be divided in two phases: software preparation and software execution. Software preparation consists in compiling and loading the software as specified by options --file and --system. During software preparation, object files are cached and will be loaded without being recompiled if a previous version exists that does not depend upon any modified sources. If no image is dumped, then software preparation happens at each invocation of the generated script. If an image is dumped then the preparation only happens at invocation of cl-launch, and the generated script will use the prepared software directly; with ECL, the load-time (but not compile-time) side-effects of software preparation are evaluated every time a dumped image is invoked. Software execution happens at every invocation, after the prepared software has been suitably loaded. First the --restart function, if provided, is called. Then, the --init forms, if provided, are evaluated.
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.
Multiple paths may be supplied that will be added to asdf:*central-registry* before any software is loaded, so that asdf may find the required systems. Each instance of option --path will specify one such path. The paths will be added in reverse order, so that the those specified earlier have priority over those specified later. You may also withhold any modification to asdf's central registry by specifying option --no-path. Or you may specify the current directory (at the time cl-launch is run) with option --path-current. The default if none of these options have been specified is --no-path. At each specification, an argument containing only alphanumerics and characters -+_,.:=%/ will be considered as a pathname; any other specification will be considered as an arbitrary Lisp expression (that will not be evaluated). You can also add things to asdf:*central-registry* in your system-wide or user configuration files for the startup of your Lisp implementation, but note that the default arguments used by cl-launch when invoking those implementations will disable system and user configuration files. See below how to change these arguments.
Options --lisp and --wrap may be used to control the way that a Common Lisp implementation is found when the software is run. Option --lisp specifies the list of Common Lisp implementations to try to use; the list is whitespace-separated, and consists in nicknames recognized by cl-launch. Option --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 the software doesn't use asdf, or if the asdf systems remain well located at runtime, then the script is pretty much standalone indeed an 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 43KiB.
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 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 --no-rc or +R specifies that cl-launch should not try to read resource files /etc/cl-launchrc and ~/.cl-launchrc.
Option --rc or -R 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.
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.
COMPILATION AND FASL CACHING
A cl-launch generated program will compile the contents of the file supplied with --file the first time it is invoked. Note that this happens even when the file contents were embedded in the script, since compiling or loading the wrapped file is equivalent to compiling or loading the original file supplied.
So as to avoid problems with badly interfering fasl files everywhere, cl-launch sets up a fasl cache to hold fasl files in a proper place. It will also modify asdf so that it too will put files in the same cache. This caching mechanism will be disabled if common-lisp-controller is present, since c-l-c version 6.0 and later already do a similar caching.
The fasl cache is a per-user, per-Lisp-implementation, per-source-pathname, mapping of source files to compiled files fasl. The fasl for a file $DIR/$FILE with be stored in directory $HOME/.cache/lisp-fasl/$IMPL/$DIR/ Here, $IMPL is a unique string generated by cl-launch in a way similar to what SLIME does, and stored in cl-launch::*implementation-name*.
You may specify an alternate cache directory instead of the default $HOME/.cache/lisp-fasl/ by setting and exporting the environment variable $LISP_FASL_CACHE You may also disable the cache altogether, by using the value NIL (uppercase). This path is stored in variable cl-launch::*lisp-fasl-cache*.
Because the cache reserves a separate directory for every Lisp implementation, it prevents common problems due to a same pathname being used by several different and incompatible implementations or versions of a same implementation to store their fasl files, resulting in conflict. This makes it easy to share source code hierarchy among users, machines, implementations.
As a variant, if you know for sure which implementation you're using and have set the variable $LISP, you can override the whole path with variable $LISP_FASL_ROOT so that fasls for code under $DIR with be stored under $LISP_FASL_ROOT/$DIR.
This feature plays well with common-lisp-controller: the clc cache will take precedence when detected (tested with common-lisp-controller 4.12 to 6.6). Hopefully, upstream versions of cl-launch and common-lisp-controller will synchronize to prevent or quickly fix any possible breakage. Due to outstanding bugs as of clc 6.17, 0.9j-20080306-4, and gclcvs 2.7.0-84.1, the clc cache is disabled for ECL and GCL.
Note that you may use symlinks to move ~/.cache/lisp-fasl/ to the place of your choice, and to equate NFS paths that vary across machines for a same directory. To distinguish paths between machines that share a common home directory but with varying directory contents mounted on given identical pathnames, you can use distinct values of $LISP_FASL_CACHE depending on the machine, and merge back whatever can be merged with symlinks.
SUPPORTED LISP IMPLEMENTATIONS
The implementations supported by current version of cl-launch are sbcl cmucl clisp ccl allegro lispworks ecl gcl Also defined are gclcvs openmcl lisp which are name variations for gcl, ccl and cmucl respectively.
Fully supported, including standalone executables: sbcl: SBCL 1.0 (1.0.21.24 needed for standalone executable) clisp: GNU CLISP 2.44 (no standalone exec before 2.48, broken before 2.36) ecl: ECL 0.9l (Beware! cache needs be cleared before to dump asd images)
Fully supported, but no standalone executables: cmucl: CMUCL 19b (recently only tested with 19d) ccl: ClozureCL 1.2 (support for OpenMCL 1.1 and earlier discontinued) gclcvs (GCL 2.7): GCL 2.7.0 ansi mode (get a recent release)
Incomplete support: gcl (GCL 2.6): GCL 2.6.7 ansi mode (no ASDF so --system not supported) allegro: Allegro 5 (not tested on recent versions) lispworks: LispWorks Professional 5.1.0 (annoying banner, no personal ed)
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 GCL 2.7 so --system won't work with an old gcl 2.6.
There are some issues regarding standalone executables on CLISP or ECL. 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.
Additionally, cl-launch supports the use of clbuild as a wrapper to invoke the Lisp implementation, with the --clbuild option.
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 clisp ccl cmucl ecl gclcvs allegro lispworks lisp gcl 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" LISP_FASL_CACHE=/var/cache/lisp-fasl # 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 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
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 -X ...options... -- For instance, you may write the following script (stripping leading spaces): #!/usr/bin/cl-launch -X --init '(format t "foo~%")' -- (format t "hello, world~%") (write cl-launch:*arguments*) (terpri) The limitation is that the first argument MUST be '-X' (upper case matters, and so does the following space actually), the last one MUST be '--' and all your other arguments (if any) must fit on the first line, although said line can be as long as you want: the kernel has a limit of 127 characters or so for this first line, but cl-launch will read the first line directly from the Lisp script, anyway.
Note that if you don't need Lisp code to be loaded from your script, with everything happening in the --file --system and --init software 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): #!/bin/sh ":" ; exec cl-launch -X -- "$0" "$@" || exit 42 (format t "It works!~%") In practice, I've found that machines with custom-compiled Linux kernels 2.6.15 and later supported #!/usr/bin/cl-launch fine with a wide variety of shells (I tried 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), whereas other machines with a standard Linux kernel 2.6.11 from debian would not support it with any shell. Maybe an issue with kernel binfmt_misc configuration?
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.
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 and LispWorks Professional. Moreover, ECL and CLISP have 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. But 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.
As of CL-Launch 2.11 and ECL 0.9l, dumping ASDF systems seems to not work reliably when some object files from previous compilation attempts are present in the cache (typically in ~/.cache/lisp-fasl/ecl*). The current known workaround is to clear (rm -rf) your cache and compile from clean.
CL-LAUNCH RUNTIME API
cl-launch provides the following Lisp functions:
Variable cl-launch:*arguments* contains the command-line arguments used to invoke the software.
Function cl-launch:getenv allows to query (but not modify) the environment variables, as in (getenv "HOME"), returning nil when the variable is unbound.
Function cl-launch:load-system takes as an argument the name of an asdf system and the keyword argument verbose, and loads specified system with specified verbosity.
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 cl-launch:compile-file-pathname* to determine the fasl pathname.
Function cl-launch:compile-file-pathname* is a variant of the similarly named ANSI CL function cl:compile-file-pathname that takes into account the fasl cache and also common-lisp-controller (if present). It works by calling cl-launch:apply-output-pathname-translations with the truename of the given source file. The specified source file must exist.
Function cl-launch:apply-pathname-translations takes a pathname as an argument, and an optional list of translations (by default, it will use those from cl-launch:*output-pathname-translations*). It will scan the list of translations, where every translation is a list of a source pathname and a destination pathname. If the source pathname matches, then the file is translated to the destination pathname.
Function cl-launch:apply-output-pathname-translations takes a pathname as an argument translates it into a pathname in the cache. If common-lisp-controller is present then the c-l-c cache is used. Otherwise, the cl-launch cache as specified by cl-launch:*output-pathname-translations* is used.
Variable cl-launch:*output-pathname-translations* is the list of translations that apply-pathname-translations will use by default. asdf, if present, will have been configured to make use of this mechanism.
Function cl-launch:quit will cause the current Lisp application to exit. It takes two optional arguments code with default value 0, and finish-output with default value t. The first is to be used as the process exit code, the second specifies whether to call finish-output on *standard-output* and *error-output*. Note that you should use (finish-output) and otherwise flush buffers as applicable before you quit, not just to be standard-compliant, but also to support ccl and any other Lisp implementation that do buffering.
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.
USING CL-LAUNCH FUNCTIONALITY IN YOUR LISP DEVELOPMENT ENVIRONMENT
When you develop programs that you will use with cl-launch, you may as well use cl-launch during development, and benefit from its fasl cache architecture.
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/cl-launch.sh")
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:oos 'asdf:load-op :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 ...)
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 cl-launch:*arguments*)" \ --path ${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. 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 ./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
Download ASDF package from http://common-lisp.net/project/xcvb/cl-launch/cl-launch.tar.gz
This page is linked from: Buildapp Creating Executables Exscribe Fare Rideau ShellScripting
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively