Re: RFC: major change to argument processing.

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Sounds very good to me.  The meta-arg stuff is not really useful if
> you can't form arguments with whitespace in them.  How does SCSH
> behave?

It describes itself as behaving exactly the way that guile behaves now
which (at least in the guile implementation) only allows one line, and
seems to have no real way to handle whitespace.

It also has a fairly complicated set of rules for handling the single
line allowed after the "\" which IMO have some strange side effects
(eg. I think it would be clearer if "" introduced an empty argument
rather than any two adjacent spaces):

  When Guile sees the meta switch `\', it parses command-line argument
  from the script file according to the following rules:
     * Each space character terminates an argument.  This means that two
       spaces in a row introduce an argument `""'.

     * The tab character is not permitted (unless you quote it with the
       backslash character, as described below), to avoid confusion.

     * The newline character terminates the sequence of arguments, and
       will also terminate a final non-empty argument.  (However, a
       newline following a space will not introduce a final empty-string
       argument; it only terminates the argument list.)

     * The backslash character is the escape character.  It escapes
       backslash, space, tab, and newline.  The ANSI C escape sequences
       like `\n' and `\t' are also supported.  These produce argument
       constituents; the two-character combination `\n' doesn't act like
       a terminating newline.  The escape sequence `\NNN' for exactly
       three octal digits reads as the character whose ASCII code is NNN.
       As above, characters produced this way are argument constituents.
       Backslash followed by other characters is not allowed.

I believe my proposed change is likely to be transparent to nearly all
of the existing scripts, and adds substantially more flexibility while
also being much easier to describe since there is one rule: args after
the \ are handled by "read", and reading terminates when a !# is hit.

Also, there are some other options that scsh handles that might be
interesting, (in particular -lm and -sfd) 

  scsh [meta-arg] [switch1 ...] [end-option arg1 ...]
      meta-arg: \ <script-file-name>

      switch: -e <entry-point>    Top-level entry point
              -o <structure>      Open structure in current package.
              -m <structure>      Switch to package.
              -n <new-package>    Switch to new package.

              -lm <module> <file-name>    Load module into config package.
              -l <file-name>              Load file into current package.
              -dm                         Do script module.
              -ds                         Do script.

      end-option: -s <script>             Specifies script to load.
                  -sfd <num>              Script from file descriptor <num>.
                  -c <expression>         Eval <expression> and exit.
                  --

> Hmm, I'd rather have this after 1.6.0.  We should not put in too many
> stuff without enough time to shake out the bugs.

Well, it looks like the implementation may be a lot simpler than what
we have now, and I'm making quick progress when I have time to deal
with it, so how about if I get it done soon, I'll post it and you can
decide.  I agree that we should be cautious, but I also feel like the
sooner we make the new syntax and "-x" available, the better.

Thanks

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