[Top][All Lists]
[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
- Command line processing opens up can of worms :>, Rob Browning, 2001/05/26
- Re: Command line processing opens up can of worms :>,
Dirk Herrmann <=
- Re: Command line processing opens up can of worms :>, Rob Browning, 2001/05/27
- Re: Command line processing opens up can of worms :>, Marius Vollmer, 2001/05/29
- Re: Command line processing opens up can of worms :>, Rob Browning, 2001/05/29
- Re: Command line processing opens up can of worms :>, Marius Vollmer, 2001/05/29
- Re: Command line processing opens up can of worms :>, Rob Browning, 2001/05/29
- Re: Command line processing opens up can of worms :>, Marius Vollmer, 2001/05/30
- Re: Command line processing opens up can of worms :>, Dirk Herrmann, 2001/05/29
- Re: Command line processing opens up can of worms :>, Marius Vollmer, 2001/05/29
Re: Command line processing opens up can of worms :>, Martin Grabmueller, 2001/05/28