[Openmcl-devel] self-contained executable library - how does it access command line arg[1]?

[Gary Byers]

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

or

$ 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
and customized.)

- 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
>> interpret
>>
>>   foo -- bar
>>
>> Is that true?
>
>  No.
>
>> 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
> this:
>
> (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[1],
> 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.
>
>
>
> Footnotes:
> [1]  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
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>