Thanks Jake for this wonderfully precise summing up of the args problem I
raised.
I see these things from this thread:
1) there is excellent tech support out there from the Rebol community
2) the Rebol developers (if jeff is representative) aren't aiming at any
kind of cross
platform compatibility except within Rebol itself, or this issue would have
surfaced
long ago. There also seems to be a bit NIHilism (Not Invented Here-ilism)
regarding
making Rebol work the way that people experienced in other environments
might expect.
3) for my own situation, though C,C++,Delphi,Java,Perl,CWL/WebL can all be
made to
behave plug-compatibly at the command line, Rebol doesn't. This screws
what I was
trying to do with Rebol: (use existing benchmark and test suite drivers
that rely on a common command line interface for the target
language/implementation under test). Too bad, it seemed kinda cute.
No, its NOT worth it to me to rework the suite drivers to make a special
fuss of Rebol.
Sean
>To: [EMAIL PROTECTED]
>From: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>Date: Fri, 14 Jul 2000 18:43:44 -0700
>Subject: [REBOL] Rebol's argument handling is broken Re:(3)
>Organization: anObject
>X-REBOL: 2.2.0.4.2 "The Internet Messaging Language (TM) WWW.REBOL.COM"
>X-MindSpring-Loop: [EMAIL PROTECTED]
>Sender: [EMAIL PROTECTED]
>X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16-9mdk i686)
>X-Accept-Language: en
>X-SELMA: [REBOL] 247086
>
>[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
>
>
>
