Command line processing opens up can of worms :>

[Rob Browning]

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.

However, there are some minor issues which I'll bring up later if we
can resolve the following major issue.

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.

There are ways we could get around this like requiring extra double
quotes in meta arguments (eeew):

  #!/usr/bin/guile \
  "-c" "(foo bar)"
  "-l" "somefile.scm"
  !#
  
or converting everything back to a string after it's "read" via an
output string port and write, but these solutions are nasty.

Any thoughts?  I'd really like as simple a set of processing rules as
possible for both command line and meta args that still preserves the
flexibility we need to allow things like -c and -x to be used as meta
args with clear quoting semantics.

Thanks

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930