#19 New saveinitmem keyword :parse-options
The patch adds a new keyword, :parse-options, to
saveinitmem. If :parse-options is NIL then all argv
parameters are passed untouched to the program as if
they were preceeded by an implicit "--". If
:parse-options is T (the default) then the saved image
parses options as usual. :parse-options has no effect
when :executable is NIL. Example:
$ (patch clisp-2.38/src ...)
$ ./configure --build kg-build-dir
...
$ cd kg-build-dir/
$ ./lisp.run -M lispinit.mem -B . -q -norc
[1]> (defun main () (prin1 *args*) (quit))
MAIN
[2]> (saveinitmem "without-parse-options" :quiet t
:norc t :init-function 'main :executable t
:parse-options nil)
1697080 ;
524288
[3]> (saveinitmem "with-parse-options" :quiet t :norc t
:init-function 'main :executable t :parse-options t)
1697224 ;
524288
[4]> (quit)
$ ./without-parse-options abc
("abc")
$ ./with-parse-options abc
*** - LOAD: A file with name abc does not exist
$
Notes:
(1) The patch is a 'diff -u oldsource newsource'.
(2) The patch is against clisp-2.38 which I downloaded
on February 6, 2006.
(3) All changes are clearly marked in 'newsource'
by "BEGIN KG-2006-02-20" and "END KG-2006-02-20". These
comments should of course be removed, but I have left
them in to make it easy to see what the patch does.
(4) Clisp must decide whether or not to parse options
before it parses any options. Hence, the decision is to
be made without access to options and before a memory
image is loaded.
(5) To figure out how the patch works, read spvw.d,
starting at "BEGIN KG-2006-02-20".
(6) For each new build of clisp, the patch fails with
probability 10^(-18). For each build it either fails
always or never fails. If it fails, it prints a warning
to standard output. If the patch fails, one should not
run the generated executable.
(7) The patch allows a programmer to 'burn the bridges'
when delivering an application developed in CLISP: It
is possible to make an executable memory dump in which
the end user is (a) unable to get to a CLISP prompt,
(b) unable to pass any options to CLISP, and (c) unable
to see at all that the application was written in LISP.
I consider this a feature, but I saw Sam Steingold
consider it a bug. There is antidote, however. It is
possible to write an 'unlocking program' which, given
an executable memory dump, sets the flag inside the
executable which reenables CLISP parsing of options.
(8) At the time of writing, the 'diff -u' file is also
available at 'http://yoa.dk/wiki/clisp/' together with
the sources before and after patching. The application
for which executable memory dumps with suppressed CLISP
option parsing would be nice to have is presented at
'http://yoa.dk/'.
diff -u oldsource newsource
Logged In: YES
user_id=5735
Originator: NO
I think the :SCRIPT option does what you want here.
if not, you can either create a new patch against the current sources,
or start a discussion on clisp-list.
:script t doesn't do it -- clisp expect a script path as an argument, and you can't say dump an image that implements ls(1).
PS: the patch is no longer available at the specified URL.
I want all downstream users to be able to gain access to the lisp prompt.
I am still unclear how to do that while surrendering all command line argument
processing downstream.