guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command line processing opens up can of worms :>


From: Dirk Herrmann
Subject: Re: Command line processing opens up can of worms :>
Date: Mon, 28 May 2001 01:56:17 +0200 (MEST)

On 26 May 2001, Rob Browning wrote:

> Switching to using the reader for meta args worked well, and code like
> this is OK now (in my local tree):
> 
>   #!/usr/bin/guile \
>   -l "foo.scm"
>   -ds
>   -x "(do something funny) (and (something-else) (entirely))"
>   -e main
>   -s
>   !#
>   ... remainder of script ...
> 
> I also managed to IMO clean up handling so that we now have an (ice-9
> script) module that contains (program-arguments), (command-line),
> (set-program-arguments! args), (guile-usage msg), etc. and script.[hc]
> is now mostly empty.  Also features.[hc] calls the functions in (ice-9
> script) when handling scm_program_arguments, etc.

Coool.

> The major issue is that code like getopt, etc presumes that all the
> arguments will be strings.  With my change to use the reader for meta
> arguments, that's not always true.  For example, given
> 
>   #!/usr/bin/guile \
>   -c (foo bar)
>   -l "somefile.scm"
>   !#
>   ...
> 
> (program-arguments) will be
> 
>   ("/usr/bin/guile" -c (foo bar) -l "somefile.scm")
> 
> i.e. it'll contain symbols and lists, as well as strings.  In many
> ways, this is a plus.  It lets you say things you couldn't otherwise,
> and without a lot of extraneous double quoting, but it breaks code
> like getopt (and potentially a lot of user scripts) that presume that
> all the arguments will be strings.

We have two issues to decide here:

* Should (program-arguments) be allowed to return something different than
  strings?

* How should the #! ... #! content be parsed into the list of program
  arguments?

To the first point:  If we were to allow other objects than strings, this
will cause trouble for command-line parsing code.  The reason is, that
arguments that come from a 'real' command line will always be strings,
while the same arguments given within the #! ... !# header could as well
be objects.  Thus, I don't see that allowing arbitrary objects in
(program-arguments) will be very helpful - the command line parser has to
deal with the string case anyway.  I'd say, make sure that
(program-arguments) returns a list of strings, and also let
set-program-arguments! check for ill-formed argument lists.

To the second point:  Independent of the first point it could still be
possible to read arbitrary objects within the #! ... !# header, as long as
it is guaranteed that they will afterwards be re-converted to strings. I
don't know whether this is preferable over to demand from the user to only
pass strings as options anyway.

In any case, I like the simplicity and well-definedness (strange word :-)
of the approach to read #! ... !# contents with (read), and I think this
is something we should stick to.

BTW, your thoughts and ideas could be valuable for the discussion of the
SRFI-22...

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]