Question

I’ve found it almost impossible to pass quoted arguments (containing spaces) to REBOL 3 scripts. For example:

rebol -q script.r "foo bar" 40

If you examine system/script/args, it contains the string "foo bar 40". This is useless! Information was lost. I need to know that "foo bar" was the first argument and 40 was the second. If I examine system/options/args, I get the following block: ["foo" "bar" "40"]. Again, useless! Information was lost.

I suspect that the solution to this is to use argument delimiters of some kind, e.g.,

rebol -q script.r 'foo bar' -n 40

This could easily be handled by PARSE, but I still don’t like it. It shouldn’t be terribly difficult for system/options/args to contain one string per passed argument.

REBOL’s a pleasure to use, and this is the first thing I’ve found with which I was really disappointed. 🙁

Answer 1

In REBOL 3, the behaviour you observe is a known bug.

(At the moment, R3 internally passes args from the OS to scripts as a single string, concatenating all original arguments in the process. Currently this process is not fully reversible, which is the cause of this bug. R3 probably should_ pass arguments as a list of strings instead, effectively preserving the original argv but stripped of arguments used by the interpreter itself.)

---

In REBOL 2, system/options/args is safer to use for command-line arguments, whereas system/script/args can be used to pass values between REBOL scripts more directly. I assume that similar behaviour will be kept for R3.

Here’s a quick script to inspect argument parsing behaviour:

REBOL []
print system/version
print "options args:"
probe system/options/args
print "script args:"
probe system/script/args

REBOL 2, on OSX:

2.7.7.2.5
options args:
["foo bar" "40"]
script args:
"foo bar 40"

REBOL 3, on OSX:

2.100.111.2.5
options args:
["foo" "bar" "40"]
script args:
"foo bar 40"