[REBOL] Rebol's argument handling is broken Re:(4)
Jeff, you seem to be missing the point by comparing REBOL to grep. Suppose I wanted to write grep (or anything else) in REBOL, I'd like it to behave just like that. I'd need a shell wrapper to hide the fact I was running the rebol interpreter with a script and I'd expect any and all args to the shell wrapper to be passed on to my script, not eaten by the rebol interpreter. If this isnt clear, here's two examples I'm working with: 1) executable file rpke.exe, runs like this... rpke -i infilename -o outfilename -e anotherfilename -v 2) java program to do the same thing, run from command line by rpke.bat, like this... rpke -i infilename -o outfilename -e anotherfilename -v The "wrapper" batch file rpke.bat looks like this... @echo off rem driver for Java version of rpke command line program jre -cp rpk.jar;rpkdemo.jar rpkdemo.JRPKE %* ... it passes all the args given to the batch file in the "%*", and these all get thru to the java class, and are not soaked up by jre. I'd like REBOL to be capable of behaving the same way. Incidentally, maybe there's some easy way to "wrap" the command line args "%*" so that the rebol interpreter doesnt notice them, and instead passes them on? Maybe some extra quotes? If the "magic" was all hidden in the .bat file then I can get the job done. (Reason - the command lines are being emitted by another script, and it neither knows or cares which implementation is actually being invoked) I'm aware that there may be flaws in the above .bat file when presented with quoted filenames containing spaces, fortunately I dont need to care about that. Hoping for a workaround, rather than waiting for the is-it-a-bug debate to conclude. Sean At 01:33 PM 18/07/00 -0800, you wrote: > > >> This bit me too. Rebol apparently parses everything that looks like an >> option on the command line, not just up to the script name. >> >> I consider this a bug and not a feature. >> >> Garold (Gary)L. JohnsonDYNAMIC Alternatives >> [EMAIL PROTECTED] > > > Grep works similarly as REBOL currently does, considering > arguments preceded by - to be switches regardless of where > they are placed. For example: > >Before and after args: > > grep -A 3 foo * -vi > >In between and after args: > > grep foo -B 10 *.txt -A 20 > > > -jeff > > >
[REBOL] Rebol's argument handling is broken Re:(4)
Jeff wrote: Grep works similarly as REBOL currently does, considering arguments preceded by - to be switches regardless of where they are placed. For example: Before and after args: grep -A 3 foo * -vi In between and after args: grep foo -B 10 *.txt -A 20 [Garold L. Johnson] That is true, and is true of many Unix programs, but AFAIK it isn't true of Perl which handles switches up to the script name and passes the rest to the script. I suggest that Perl is a better analogy to REBOL than is grep. The standard mode for getopt in Perl (which is patterned after the Unix version used in C) is to process all arguments regardless of position leaving only files in the argument list, but this is still within the script and not being intercepted by the Perl interpreter itself. Thanks, Garold (Gary) L. Johnson DYNAMIC Alternatives [EMAIL PROTECTED]
[REBOL] Rebol's argument handling is broken Re:(4)
[EMAIL PROTECTED] wrote: > Grep works similarly as REBOL currently does, considering > arguments preceded by - to be switches regardless of where > they are placed. For example: > > Before and after args: > > grep -A 3 foo * -vi > > In between and after args: > > grep foo -B 10 *.txt -A 20 Interesting.. But grep isn't a language interpreter, and that makes *all* the difference! :) -Jake
[REBOL] Rebol's argument handling is broken Re:(4)
Howdy, Sean: > 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. Naw. Be patient. These things are still evolving. Under windows and mac we have drag and drop support for scripts, and we arrange associations so you can start a script by double clicking on it. Similarly, we should expect REBOL in unix environments to follow suit with the way other applications fit in. It was my own concern with improving the way REBOL operates from the command line that set me off on exploring this issue to begin with. As a result, I've gotten a lot of good feedback from people (thanks) and the info is being formulated into improved arg handling which (hopefully) will meet all our needs and make us all happy. Cheers-- -jeff
[REBOL] Rebol's argument handling is broken Re:(4)
[EMAIL PROTECTED] wrote: > DOing formed blocks is sort of inelegant. You're taking a > REBOL data structure, a block, and then turning it into a > string. By the DOing the string the interpreter actually > turns the string back into a block of REBOL data types > before evaluating it. It's not very optimal. Just DOing > the original string ends up being half as much work. Yes, but either way it doesn't seem like a whole lot of work, unless you're talking about a REALLY long command-line on a really slow machine. :-) > Another idea that was brought up was that you could have > more than one view of the command line args available, so > those that want the separation of args would have it in a > block somewhere, and those that want just a doable string > would have it somewhere else. Best of both methods > approach. > > Would that work for us disgruntled REBOL command liners? (-: Sounds great to me! -Jake
[REBOL] Rebol's argument handling is broken Re:(4)
Hi, After coding on the C64 and before hitting the bed I'll write quickly... Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > Another idea that was brought up was that you could have > more than one view of the command line args available, so > those that want the separation of args would have it in a > block somewhere, and those that want just a doable string > would have it somewhere else. Best of both methods > approach. > > Would that work for us disgruntled REBOL command liners? (-: Well, that seems then to be the best approach, it won't even break existing scripts. To get the arguments in a block has definately it's uses. And there is no idea giving arguments in some rebol-specific way, as you suggested earlier. About doable arguments, you said (I already clipped that part away, sorry) that it is inefficient, maybe so but the args are parsed only once and starting rebol takes it's time anyway... For what kind of things 'lot's of people' use doable command-line arguments? (I'm just being curious :) yours, Jussi -- Jussi HagmanCS in Åbo Akademi University Studentbyn 4 D 33 [EMAIL PROTECTED] 20540 Åbo [EMAIL PROTECTED] Finland
[REBOL] Rebol's argument handling is broken Re:(4)
>From: [EMAIL PROTECTED] >Subject: [REBOL] Rebol's argument handling is broken Re:(3) >Date: Wed, 12 Jul 2000 18:01:35 -0800 > >Howdy, Jake: > > > 1) How many people are going to *want* an immediately DOable > > REBOL expression? > > Lots of people! ;-) agreed. > > Maybe I'm missing something, but what about FORM? For > > example, assume I pass this to my script: > > DOing formed blocks is sort of inelegant. You're taking a > REBOL data structure, a block, and then turning it into a > string. By the DOing the string the interpreter actually > turns the string back into a block of REBOL data types > before evaluating it. It's not very optimal. Just DOing > the original string ends up being half as much work. Yes, but only "sort of inelegant". It is extra work, but only involves one extra word of rebol code (no big deal), and the wasted processing time is insignificant compared to the overhead of starting the rebol interpreter to execute a single line of code. So it seems liek a reasonable trade-off to me. > I do agree with what you're saying, though, about the need > to distinguish command line args. Believe me-- I want REBOL > to excel at command line integration as much as the next > guy! As the next guy, I must say that that's quite a bit. ;-) > Another idea that was brought up was that you could have > more than one view of the command line args available, so > those that want the separation of args would have it in a > block somewhere, and those that want just a doable string > would have it somewhere else. Best of both methods > approach. > > Would that work for us disgruntled REBOL command liners? (-: I like that solution, it sounds like a wonderful enhancement, but is adding the code to provide that any more elegant than just using 'form on an argument block? If so then I'd vote for this, if not - don't clutter up the system object with semi-redundant info. > > Command-linely yours, > > -jeff > Cal Dixon ([EMAIL PROTECTED]) -><- Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
