[EMAIL PROTECTED] wrote:

>   If you pass items beginning with a dash (-switch) as
>   arguments to the script, how would you suggest REBOL find
>   it's own command line switches?

To make this work as Sean expected, the answer is simple:  REBOL should
find its own command line switches *before* the filename of the REBOL
script, and pass anything *after* the name of the REBOL script untouched
to the program.  This is how the UNIX shell, and I believe Perl, Python,
TCL, and every other popular scripting language work.  I'll walk you
through an example of how this works in practice.

Here's a simple shell script that echoes a list of its arguments:

#!/bin/sh
echo $*

I can run this script passing arguments that bash would normally pay
attention to, and they are happily passed to it, whether I do this:

$ sh test.sh --version
--version

or this:

$ chmod +x test.sh
$ ./test.sh --version
--version

So how do I pass arguments that I want bash to listen to?  I would have
to either say:

$ sh --version test.sh
GNU bash, version 2.04.3(1)-release (i586-mandrake-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.

or modify the script to something like:

#!/bin/sh --version
echo $*

$ ./test.sh
GNU bash, version 2.04.3(1)-release (i586-mandrake-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.

BTW, when you use the "#!" trick on UNIX to automatically launch the
interpreter, what gets passed to the interpreter's argv array?  Again,
an example makes this crystal clear.  Here's a little C program that
prints its args:

#include <stdio.h>

int main(int argc, char **argv) {
  int i;
  for(i=0; i<argc; i++) {
        printf("%s\n", argv[i]);
    }
  return 0;
}

Let's cook up another simple "script" to see what's happening:

#!./test -a -b -c
this is all ignored

When I run it, I get something a little surprising:

$ chmod +x test2.sh
$ ./test2.sh -d -e -f
test
-a -b -c
./test2.sh
-d
-e
-f

argv[0] is the name of my "interpreter".  argv[1] has all of the
arguments from the top line lumped together.  This is the part that
surprised me, as it means that either you're limited to passing a single
argument to the interpreter, or the interpreter has to be either smart
enough or dumb enough (depending on how you look at it) to work properly
with several options packed into a single argv slot.  More on this in a
little bit, but I should point out that this happened with both Linux
and AIX, so it probably holds true for other UNIX's too.  Finally, the
kernel passes the name of the script in to argv[2], and the arguments on
the command-line in the remaining argv slots.

So, how does REBOL compare to the humble bash shell?  First, both fail
miserably in allowing more than one option at a time to be passed on the
#! line, but I'm not too surprised at this, considering how the kernel
is passing the options to it.  I've seen lots of example REBOL CGI's
that start out like:

#!/usr/local/bin/rebol -cs

which works, since both options are glommed into one "word" either way. 
But if you try to do:

#!/usr/local/bin/rebol -c -s

You get a warning about proper command line usage, indicating to me that
REBOL clearly doesn't understand being passed, essentially:

$ rebol "-c -s"

instead of:

$ rebol -c -s

As I said, bash fails in the same way, so I guess this is just a UNIX
limitation and I'm not suggesting that you go out of your way to "fix"
REBOL.  However, where bash succeeds and REBOL fails is, as Sean first
pointed out, that bash happily passes along arguments given AFTER the
script name untouched, while REBOL insists on munching up ANYTHING that
starts with a -, no matter where in the commandline, making REBOL, as
Sean says, unsuitable for creating REBOL scripts that look and feel like
other apps on the system!

Now I'm not saying that the UNIX shell is beyond improvement, and I
certainly appreciate the very cross-platform nature of REBOL, but in
this case, I think acting like the natives makes a lot of sense.  "When
in Rome..." and all that.  Even if other OS's don't have the #! trick
that makes it possible to write interpreted scripts that are
indistinguishable in terms of command-line usage from native programs, I
don't see the benefit of allowing REBOL commandline options to be
randomly intermingled with options to be passed to the script.  Is there
ANY benefit to being able to do, for example:

$ ./print-my-args.r -c a -s b
"a b"

-Jake

Reply via email to