Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

Script args

 [1/4] from: jonkelly::fastmail::fm at: 29-Jul-2007 11:12

Hi, I can't seem to get args working?? I'm running View (Windows) Well, I thought before I posted I should check google and found the FAQ entry. I had mis-read the help text and was using do %t6.r /args "test1 "test2" but there was no error, which seems strange. So what is /args in that expression? Is it a work, but words can't contain the / character. Hmmm what does this mean ...
>> /args: "testing"
== "testing"
>> /args
== /args
>> print /args
>> print mold /args
>> help /args
/args is a refinement
Anyway, there seems to be some discrepancy anyway. When I run a script via "rebol t6.r test1 test2", I can see the args in three places: system/script/parent/args => "test1 test2" system/script/args => "test1 test2" system/options/args => [ "test1" "test2" ] OK, that's good, but what is the script's parent? (the interpeter?) So, now I want to run this script from another script (or the console). do/args %t6.r "test1 test2" the only args that is set is system/script/args and that hardly seems simple. But more; when I do xx: load %t6.r do/args xx "test1 test2" NONE of the args is set. t6.r is ... ------------------ REBOL [ Title: "Testing running scripts" Date: 29-Jul-2007 File: %t7.r Author: "Jonathan Kelly" Version: 0.0.1 ] print [ "A" type? system/script/args mold system/script/args ] print [ "B" type? system/options/args mold system/options/args ] print "T6 system/script" print mold system/script print "T6 system/options" print mold system/options ask "finished"

 [2/4] from: btiffin:rogers at: 29-Jul-2007 2:02

Hi, I can't say I completely get this either. But for do/args it only works for scripts. And it always sets system/script/args
>> help do <snip>
REFINEMENTS: /args -- If value is a script, this will set its system/script/args arg -- Args passed to a script. Normally a string. (Type: any) It's one of those things that takes some getting used to, but it is design intent. And command line arguments, are best accessed through system/options/args, but will show up in those other places as one big string. system/script/parent...isn't set for my Linux version with scripts that are started up with REBOL. When you were playing with /something in REBOL it becomes a little weird too. /anything is a valid REBOL value. It can be passed around, set to variables etc. a: /abc help a A is a refinement of value: /abc So if you mistype or misplace an actual refinement, it is just a value (as are real refinements in the "right" place but in that case the function header parser does a few other things for you when it detects a "match"). /abc: "test" is a weird one. It will become pretty hard to retrieve without looking into get and to- functions, maybe some other wierdness. There are a few REBOL guru's that may explain what's going on. And yep, it can get confusing as you try and figure out what the lexical scanner is actually up to sometimes. Again, hope that helps a little. Cheers, Brian On Saturday 28 July 2007 21:12, Jonathan Kelly wrote:

 [3/4] from: jonkelly::fastmail::fm at: 29-Jul-2007 17:18

Brian, Brian Tiffin wrote:
> Hi, > I can't say I completely get this either. But for do/args it only works
<<quoted lines omitted: 8>>
> system/options/args, but will show up in those other places as one big > string.
Its best to access system/options/args except that "do/args" only populates the system/script/args. The script has to have special code to deal with whether it's being called directly, or from another script, or you HAVE to use system/script/args, as that's the only consistent data element. Then again, it doesn't work at all if you "load" the script and then "do/args" it. I'd call it a bug, but if it's argued not to be, it surely breaks the "simple" design philosophy. Anyway, it annoys me. :)
> system/script/parent...isn't set for my Linux version with scripts

 [4/4] from: btiffin::rogers::com at: 29-Jul-2007 15:20

Jonathan, I'd nod my head in agreement to that last line it is annoying, but in a pleasant REBOL kind of way. :) We still have to wait a few more sleeps, but there have been promises made about simplifying Programming In The Large with REBOL version 3, and multiple scripts in a project with argument passing will hopefully get a good work over. As well as making R3 more shell scriptable. I look forward to a day where I can log into up my GNU/Linux box with /usr/bin/rebol as the shell, but for now those are just hopes and dreams, realistic hopes and dreams, but still a few more sleeps before coming to grips with the true potential of R3. R2 is capable of doing almost everything, but it usually involves experimenting to make things fit and you have approach each problem knowing that the solution you think will work my not be the solution of best fit. Cheers, Brian On Sunday 29 July 2007 03:18, Jonathan Kelly wrote:

  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted