Re: Running non-scheme scripts: some thoughts

[Neil Jerram]

William ML Leslie <address@hidden> writes:

> For most entry-points, there is no extension. When you install your
> program, you normally install it as /usr/bin/foo, rather than
> /usr/bin/foo.[ss|scm|py|js|whatever].  This is the motivation for
> guile-foo symlinks or --lang options.  I favour the symlinks slightly,
> because not all languages are going to work with guile's extended
> mesh-wow system, and indirection via env already costs you one
> argument.

Yes, and in the hoped future when Guile runs Python better and faster
than any other implementation, we certainly need the symlinks so that
someone can do

# cd /usr/bin && rm python && ln -s guile-python python

to let Guile run all existing Python programs on their system.

Then, clearly, "guile-python" needs to handle all the command line
arguments that are traditional for Python - not the traditional Guile
arguments - and munge them into a suitable startup incantation/sequence
for Guile.

And then there are two detailed arguments which both suggest handling
"guile-python" within the main Guile executable, instead of in an
accompanying shell script.  Firstly it's more flexible to transform
guile-python arguments directly into Guile startup code, instead of a
two step transformation first to traditional Guile arguments and then to
code.  (What if there isn't an appropriate traditional Guile argument?)
Secondly it feels more maintainable and integrated to have that logic
within the main Guile code, instead of in a shell script to one side.

I think that means the necessary support should be added to
compile-shell-switches in (ice-9 command-line), and to the C code in
script.c that calls that, to allow compile-shell-switches to set up for
different languages according to $0.

Regards,
        Neil