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

[Gary Byers]

1)  It's trivial to write a shell script to process arguments however you
     want to and pass them to ccl after -- .  There's no reason to expose
     the user to the horrors of -- this, though I think that people who
     worry about this issue probably overestimate the degree to which
     end users share their concern.

2)  See 1.

I completely fail to see the issue here.

The hard part here is writing a useful application; that's often a lot of
work.  If the thought that you'd have to write a shell script so that 
your application can be invoked with a single argument is holding you up,
you should probably try to get past that.

It's believable that end users will care about what your program does and
how well it does it.  It's substantially less belivevable that anyone will
care about how it's invoked: people run Java code and C# code and C code
linked to toolkits and frameworks that do their own command-line processing
all the time, and when they run this code from the command line they often
do so via a shell script (or .bat file, or whatever).  As far as I can tell,
no one cares about this (not the end users, or the authors of all of this
C/C#/Java code out in the real world) besides whoever decides to raise the
issue on this list every few months.

I don't get it.  It's slightly harder to write a shell script than it is
to not write one, and it's probably slightly harder to figure out how to
package and distribute that than it would be to skip that step.  In the
context of writing an application that's worth distributing (or that you'd
want to use more than once), these seem to be trivially small steps.

I don't think that it's the right idea, but it's a fairly small change
to say that if the kernel on startup notes that it contains an
embedded heap image (the product of (SAVE-APPLICATION
... :PREPEND-KERNEL T) or equivalent), then neither the kernel nor
lisp startup code processes any arguments and they're all just
available to the application in *UNPROCESSED-COMMAND-LINE-ARGUMENTS*
as if they had followed --.  That's wrong in several ways: whether
there's a single executable file or not doesn't have much to do with
how arguments are processed, but people seem to want it to; there are
some obscure arguments (mostly having to do with stack and heap sizes)
that are sometimes the only way to run in broken virtual environments
and those arguments have to be processed by kernel (often fairly early),
but pointing this out hasn't done any good in the past and there's no
reason to believe that it would this time.

Making this change would at least make the point that this isn't
necessarily what you want; it might be adequate for some (perhaps
many) applications.  Note that it's essentially the same behavior
as you'd get from:

#!/bin/sh
exec /path/to/executable -- $@

though the shell script would also work if there was a separate
/path/to/executable.image.

It's occasionally necessary (usually to work around OS/virtualization
issues) to start the image with obscure options related to heap/stack
sizes.  It's even more obscure but is occasionally useful to tell a
standalone executable to load a heap image other than the one that's
embedded in the executable file.  The change outlined above makes doing
these kinds of things hard (or virtually impossible; it might be possible
to use environment variables instead of command-line args to specify obscure
kernel options.  I think that someone suggested that obscure kernel options
could be accepted and processed as long as they started with three dashes ...)

Exactly what mixture of kernel/CCL/application-specific argument processing
is appropriate for an application is likely ... application-specific.  Changing
CCL's default behavior (because of the presence of an embedded heap image ?
Because of some option bits in that image ?) in ways that were fully general
would seem a lot more interesting to me than it does if there weren't already
straightforward ways of achieving the same effects via shell scripts.

Writing and distributing a shell script has non-zero cost, but that
cost is likely to be very close to zero in practice.  Some people seem
to express aversion to the idea that seems disproportionate to the actual
cost, and I think that we need to explore the reasons for this.

I'd try to do so if I had any idea of what those reasons are.  I get
the sort of vague impression that people think that it's more macho to
avoid shell scripts and that people hear the suggestion that they're a
better solution as a challenge to their manhood or something, but that
couldn't be the issue (since everyone knows that the exact opposite is
true.  Obviously.)


On Wed, 28 Dec 2011, Mark H. David 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?  Say it ain't so.  If this is documented with the doc for 
> command line args or
> saving applications, I completely missed it.  If not, I wish Clozure would 
> please add that.
>
> Thanks!
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>