actually, I do not write these #rebol -s %incl.r "...", I just click on the file
and to encap it, I use right-click
...and it does not work just in Windows, the same holds for Linux
I run all my REBOL scripts using F10 key from my code editor (which launches "rebol -s" on the script), having to use a wrapper script won't fit well my way of working. F11 encaps the current script directly with /Pro, F12 encaps it with /CommandView. :-)
that is not a problem, why there is any problem in using rebol -s %incl instead of rebol -s?
I guess I shouldn't be able to use %do on any such script from console anymore?
sorry: do instead of %do
just use INCLUDE
(it actually even finds the script for you, as opposed to DO which does not have a search capability)
for example, I write:
and do not care where the script is, since INCLUDE finds it for me
How does it avoid collisions between similar script names in different include folders?
It does mean relying on INCLUDE as a normal part of your workflow and approach, but I would have a hard time giving it up now.
You can use the #include-check directive to catch multiple includes, so your include-path gives you control.
it uses the INCLUDE-CTX/PATH search path variable, where the first found first served approach is used. Also, you can adjust your path at any time, which is being done by some scripts to "shrink" the search area
...and you can alway just write: INCLUDE-CTX/PATH: [%.] which uses only the current directory for search
I would like to see INCLUDE be standard, perhaps with a refinment on DO (or just have it work that way by default), simply because INCLUDE doesn't imply execution the way DO does.
Gregg: I use the same workflow for my REBOL work since 10 years...it's uneasy to change that, unless I can convince myself that the gains are worth the effort of changing the habits. :-)
Well, Gregg mentioned that he would not want to give up on INCLUDE because it saves time in a significant way
I'm the same way. It took me a while to transition to INCLUDE, but I'm glad I did.