Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> What once was a string is now a block containing a string. Yeah
> I know: that's silly. The change slipped in there by accident
> while the args passing mechanism was being revamped. (The args
> passing mechanism used to have a size limitation. While that
> limitation was being fixed there was a proposed plan to change
> the args string to a pre-scanned block. However, that plan was
> decided against but some intermediate code was accidently left
> in.
The plan was decided against? Passing commandline arguments in a block
(or similar) is the classical solution that has been proven to work
well. In my opinion it is a superior solution compared to passing them
as a string.
Passing arguments as a string makes it impossible to parse the
arguments in a platform independent fashion. Escaping various chars,
like spaces in arguments varies across platforms and even across
shells. I'm not looking forward to writing a commandline parsing
function that takes care of all possible platforms, and including it
in all of my scripts that take command-line arguments.
At the present that is not even possible, because system/string/args
is not an exact copy of the argument. It might even be impossible to
obtain one, it depends on the platform. system/script/args is
obviously construed, pardon my perl,as follows:
foreach $arg (@ARGV) {
$script_args = $script_args . $arg;
}
That is when I call a Rebol script with a following commandline
(using bash):
$ argtest.r "Spa ce" Another\ File.txt
the contents of system/script/args is
["Spa ce Another File.txt"]
>From there it is impossible to say which were the original arguments,
one could try to be clever and test for all the combinations and find out
whether there exists a file in that name. This would be a very bad
solution, for various reasons, and all the arguments are not always files.
SUGGESTION: As passing arguments as a string to a script generates
undesireable results when there exists spaces in arguments, it would be
best to return arguments as a block of strings. The system/script/args
of the previous example would then render to:
["Spa ce" "Another File.txt"]
There would be no information lost, like there is with the current
solution, and the argunentlist would be easy to access in script,
compared to the "return exact argument string" -solution which might
be impossible to implement and definately platform dependent.
As this probably is the suggestion already discussed and turned down I
would like to hear the reason and a work around for us, who use spaces
in filenames.
Yours,
Jussi
--
Jussi Hagman CS in �bo Akademi University
Studentbyn 4 D 33 [EMAIL PROTECTED]
20540 �bo [EMAIL PROTECTED]
Finland
