[REBOL] SHELL cmd exec using CALL in View 1.3
From: gerardcote::sympatico::ca at: 11-Jan-2004 16:48
While I continued to study the way the new View 1.3 integrates the CALL mechanism, I
found what I will name some limitations (that
were described however in the official REBOL DOC under the SHELL command.
1. The Call mechanism when used with the Windows OS forces the opened console window
to close itself with a Quit as soon as the
external command execution has completed. The user normally can't see what was displayed
and can't play either with this console to
edit/test further the global context resulting from the exec if he desires to do so.
2. The Call/output doesn't seem to create and fill the expected file with the results
outputted when used - an empty file is created
and nothing else.
The test code used to exercise the Call is copied below. It is extracted from the complete
joined my-easy-vid-coder.r script which
is itself based from the original easy-vid.r script from Carl.
TO START MY ORIGINAL SCRIPT:
do %"/E/Installation de logiciel/REBOL Scripts/Tutorials/my-easy-vid-coder.r"
THE NEW SCRIPT GENERATED BY THE ORIGINAL SCRIPT ABOVE (%my-easy-vid-coder.r) is :
results: [this block has 5 elements]
print fourth results
not-used: ask "Press Enter to leave"
NOTE: To stop the script while executed - before the exec is finisehd and the Console
Window is closed - I added he last 3 lines
above - I have not yet got the way to add them dynamically at the end of the word 'xcode
which the original script uses to contain
the above text - a copy is also created in %xcode.r before submitting it for execution
using the CALL mechanism as follows :
call/output "E:\Installation de logiciel\REBOL\View 1.3 - Betas testing\rebview1224031.exe
-s xcode.r" %results.txt print read
NOTE: Here again I added an extra part (print read %resutlts.txt) to test the content
of the created %results.txt file that normally
would contain what appears as output on the Console window during the execution (The
number 5 is displayed and should appear in the
file too - I think !).
Am I right with these conclusions or not ?
Is there a way to circumvent any of these or not ?
As it currently stands I don't see the real usefulness of having a script like easy-vid.r
or any other script that would lauch
another REBOL script during some CLICK and PLAY demo app - as I planned it initially...
May be I 'm asking to much from REBOL for the time being and I'll have to wait until
everything is in place ...
Finally I think that if REBOL internally permitted to launch and EXEC of another copy
of ITSELF to run a script that must be tested
in a manner like this (that is from an easy-vid.r environment) this could be the optimal
solution since when comparing the EXEC
times on my slow machine, the original easy-vid.r code that doesn't rely upon the external
SHELL mechanism for the CALL is the clear
I'm sure this is not new to advanced rebolers but it was a useful exercise to me after
so long an absence.
Since I can't go further in this direction, I'm now ready to pursue the next part of
my personal plan, that is to help complete the
OFFICIAL REBOL DOC with coding examples for each DICTIONARY word (as much as I can for
I know many of them are already included in the DOC but too many are missing for me and
I find it annoying and a lot of wasted time
to guess using trial and error each time I need some new refinement just to catch how
things really work everytime I need something
that I consider would generally be so simple - if it were a bit more documented.
I also recall everybody (Jason, Robert, ...) that I am also voluntary to help write/edit/review
some part of the planned and coming
doc - as much as I will be able to juggle with. After creating my small accompanying
coding examples I hope I will be better
prepared to help others in this way.