[EMAIL PROTECTED] wrote:
> The argument passing scheme for REBOL needs to address two
> things: 1) Providing args from command line, of course
> and 2) providing an immediately DOable REBOL expression.
1) How many people are going to *want* an immediately DOable REBOL
expression? I think a lot more people are going to want something
that's easy for them to parse. And a block is definitely easier to
parse, and less ambiguous, as Jussi said, than a string.
> With just a string for command line args, the second case
> is easy-- just do the system/options/args. In the first
> case there are situations where the distinction between
> args is unrecoverable, however you can force distinctions
> using escaped quotes, eg:
>
> \"first arg\" \"second arg\"
>
> or
>
> {first arg} {second arg}
2) If people are going to try to use REBOL to write command-line scripts
for others to use, they're going to want to make them behave like native
scripts, and that means escaping spaces in the same way that
command-line programs written in C or Perl or bash do.. Having to escape
quotes or use an alternate quote character is UGLY! Not allowing REBOL
scripters to get at information that would be available to them in ANY
other scripting language is also ugly.
> If you get a block of separate args in strings then the
> result is not easily DOable. The alternative is to have
> the args prescanned (essentially the LOAD of the command
> line args). The prescan creates a potential for
> syntax errors in the command line arguments preventing a
> script from running. That's not very advantageous.
Maybe I'm missing something, but what about FORM? For example, assume I
pass this to my script:
$ myscript.r loop 5 [print "foo"]
If split into a block, as Jussi suggests, this might look like:
["loop" "5" "[print" {"foo"]}]
Watch as REBOL works its magic and recovers the original string:
>> cmd: ["loop" "5" "[print" {"foo"]}]
== ["loop" "5" "[print" {"foo"]}]
>> form cmd
== {loop 5 [print "foo"]}
>> do form cmd
foo
foo
foo
foo
foo
Looks good to me! Is there a case where this wouldn't work?
> In the end, it was decided the best course of action was
> to leave it as it is because people COULD make delimiters
> using shell escaping measures and what not.
As I said, it seems like the wrong solution to me.
> So that's what the reasoning was. Make sense?
Not really. :-) I definitely agree with Jussi on this one.
-Jake
