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

[Mark H. David]

I'm trying to do something pretty quick.  I don't claim this is an 
application worth
distributing.  We're using this in house.  So what's wrong with that?  
So, I DO think it's right
for Lisp's to in general to support creating simple 
not-necessarily-that-distributable executables.
For the "ultimate", I could see doing a lot of things really 
differently.  I might not even use Lisp.
Somewhere along the evolution I'd surely use something like Didier's 
sophisticated command
line processor.   But why can't I do my simple thing now?  I don't hear 
good reasons.

In our case, it's an executable that starts a hunchentoot
web server on port 8080 by default, or on the port specified by arg 1 if 
provided.

I have a function that saves an executable image on all my Lisps (SBCL, 
CCL).

Then I have a function that grabs arg 1 from the list #+sbcl <some var> 
#+ccl <some var>
(that's all the "porting" I have to do), and parses out the integer in 
arg 1 if present.  That's
all I need.

Regarding doing scripts, well, it complicates the save-image abstraction 
I've
got to have this work so differently on SBCL (and any other Lisp I've 
ever known about)
vs. CCL.  If I really have to do a script, I'll have to do it for both 
SBCL and CCL.

So then the other thing Gary trivializes a bit too much is creating a 
script.

First the part about "/path/to", and then the part about this having to 
run on Windows
in addition to Unix (= Mac?).

The functionality you get with an executable is you can move it to any 
location in the
file system, and call it from any location in the file system, and it 
just works, or at least
getting it to start up and do its thing is not prevented per se by where 
it's located and where
you call it from.

Now, with a script + executable, you have to move two files.

OK, maybe having to move two files now is not that big a deal, but it is 
rather simpler if
there's just one.

But then: we'd have to either hardcode the /path/to part of it, or get 
into having some environment
variable to control it or have it figure out the location of the 
script.  I don't know a trivial way to really
get the directory the script is in.  There are lots of google 
discussions about how to do this in
various shells.  I think some work OK in some cases, but then don't work 
if you've got links or
other complications.  And there's fun with quoting whitespace ("path 
with space/to") in whatever
scripting language you've got.  This is the joy of doing it just for 
unix. Let's assume this works
for Mac.

But then there's Windows.  So, now I've got to do this all for windows.  
Besides / -> \, there
is a new world of fun google'able discussions about how to figure out 
the script directory.
(And/or new environment variable conventions, if you want to go that route.)

One other thing about an executable: when you do control-c to interrupt 
it, it just dies or does
whatever it does.  In a script, at least on Windows, it asks if you want 
to interrupt the batch
job.   It's just another oddity and annoyance.

If there were a really good reason for this simple thing I want to do to 
be "trivial effort" (or
whatever), I could see being for it.  But there's really no reason -- 
just the historical one of handling
the one-arg case of supplying the image name.  I think there's a really 
good case for continuing to
handle that IFF the image is not embedded, for compatibility with past 
practice and
consistency with doc (I assume it's doc'd), and for the simplicity it 
provides for that functionality.
I think: of course it makes perfect sense for an imageless executable to 
snarf the first arg
as the image name -- it needs an image name, and on the other hand it 
makes perfect sense
for an embedded-image executable to not do that -- it doesn't need an 
image name.

Then the only thing needed is to doc and make available without needing 
double ::'s the variable
with all the command line args.

So, those are my thoughts, and hope this helps folks better understand.

Thanks,

Mark

On 12/29/2011 8:02 AM, Gary Byers wrote:
> 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
>>
>>