[Openmcl-devel] self-contained executable library - how does it access command line arg?
gb at clozure.com
Thu Dec 29 07:02:09 CST 2011
If CCL is invoked with a single argument whose first character isn't
#\-, that argument is interpreted by the kernel as the name of a heap
image to load.
Arguments that are processed by the kernel are removed from argc/argv
and don't appear in CCL:*COMMAND-LINE-ARGUMENT-LIST* (which is exported
but not documented.)
So what Mark was asking to be told wasn't so about
$ foo bar
$ ccl64 bar
is indeed so, unless your library changes the kernel's behavior or unless
foo is a shell script which inserts a "--" in the right place.
Some people have argued that this treatment of a single argument as shorthand
for "--image-name arg" or "-I arg" should be suppressed if the kernel contains
an embedded image. That'd be a (minor) incompatible change, and I'd personally
prefer to just drop the shorthand rather than have it behave differently in
the embedded/non-embedded cases.
The only reason that I can think of to continue to support the single-arg
shorthand is that the feature's been around for a long time and some people
may be used to it (and some ... shell scripts ... used to invoke a customized
CCL might use that shorthand, though that's probably less likely.)
The strongest reason that I can think of for dropping support for the shorthand
is that it would cause large parts of this discussion to die, and that's pretty
attractive at the moment.
I changed this in the trunk a little while ago (in r15159). This means that:
- something like
$ ccl64 foo
will no longer be treated as shorthand for
$ ccl64 --image-name foo
and some habits/shell scripts/.emacs files/etc may need to change.
- the standard toplevel-function will complain about the unrecognized argument
and exit. (There's a separate issue as to how this behavior can be extended
- an image saved with a custom toplevel function will see "foo" on
*COMMAND-LINE-ARGUMENTS-LIST* and can process it however it wants to.
- all of the above is true regardless of whether the executable contains
an embedded heap image or not.
- there may still be issues related to whether a particular application
wants arguments to be processed by the kernel (and, if applicable, by
the standard toplevel function) and it still seems like shell scripts
offer the greatest application-specific flexibility. The magic treatment
of a single non-option argument is a separate issue, and hopefully that
issue won't come up as often without that special treatment.
On Thu, 29 Dec 2011, Didier Verna wrote:
> "Mark H. David" <mhd at yv.org> wrote:
>> I don't see any way to get the first arg to a self-contained
>> executable. I find it hard to believe you cannot save an exe as "foo",
>> and then have your application interpret
>> foo bar
>> typed on the command line however it wants.
>> and from trying stuff out is that you cannot get that. You can only have it
>> foo -- bar
>> Is that true?
>> Say it ain't so.
> it ain't so.
> CCL has a ccl::*command-line-argument-list* variable for that. You can
> access cmdline arguments after dumping an executable with something like
> (ccl:save-application name
> :toplevel-function #'function
> :init-file nil
> :error-handler :quit
> :prepend-kernel t)
> You may be interested in my command-line options management library,
> which provides portable cmdline manipulation and executable dumping
> across several compilers, including CCL. If you're not interested in the
> whole stuff, take a look at the file util.lisp.
>  http://www.lrde.epita.fr/~didier/software/lisp/clon.php
> Resistance is futile. You will be jazzimilated.
> Scientific site: http://www.lrde.epita.fr/~didier
> Music (Jazz) site: http://www.didierverna.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel