SHELL cmd exec using CALL in View 1.3
[1/11] from: gerardcote::sympatico::ca at: 11-Jan-2004 16:48
Hi list,
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
print ""
not-used: ask "Press Enter to leave"
unset 'not-used
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
%results.txt
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
winner.
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
now).
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.
Regards,
Gerard
[2/11] from: gerardcote:sympatico:ca at: 11-Jan-2004 17:16
Oups! I forgot to join the entire file as a reference to those interested.
Here it is.
Regards,
Gerard
P.S. I also looked back to the REBOL Command SHELL interface (Official Docs) and it seems
that one way to let REBOL do leave an
executed console window opened would necessitate a new switch to use when launching REBOL
as in REBOL -k (for keep open)
and this would be bypassing the normal internals REBOL is using. In normal case REBOL
automatically adds intrnally the /c switch
with the CALL under Windows OS as if the coders had used CALL/c to automatically close
the console window when finished...
-- Binary/unsupported file stripped by Ecartis --
-- Type: text/x-rebol
-- File: my-easy-vid-coder.r
[3/11] from: petr:krenzelok:trz:cz at: 12-Jan-2004 10:11
Gerard Cote wrote:
>Oups! I forgot to join the entire file as a reference to those interested.
>Here it is.
<<quoted lines omitted: 4>>
>and this would be bypassing the normal internals REBOL is using. In normal case REBOL
automatically adds intrnally the /c switch
>with the CALL under Windows OS as if the coders had used CALL/c to automatically close
the console window when finished...
What about call/wait?
-pekr-
[4/11] from: nitsch-lists:netcologne at: 12-Jan-2004 11:47
Am Sonntag 11 Januar 2004 22:48 schrieb Gerard Cote:
> Hi list,
> call/output "E:\Installation de logiciel\REBOL\View 1.3 - Betas
> testing\rebview1224031.exe -s xcode.r" %results.txt print read %results.txt
first look: can you check for whitespace-handling? i would expect you need ""
around the exe-path, like
call {"wsp path\rebol.exe" args}
in your example i expect "E:\Installation" is called with the rest as
argument.
[5/11] from: g:santilli:tiscalinet:it at: 12-Jan-2004 11:52
Hi Gerard,
On Sunday, January 11, 2004, 10:48:35 PM, you wrote:
GC> 2. The Call/output doesn't seem to create and fill the
GC> expected file with the results outputted when used - an empty
GC> file is created
GC> and nothing else.
CALL/OUTPUT actually works correctly on Windows. You can also
redirect the output to a string, like:
>> call/output "ping localhost" s: ""
== 0
>> print s
Esecuzione di Ping GABRIELE [::1] con 32 byte di dati:
Risposta da ::1: durata<1ms
Risposta da ::1: durata<1ms
Risposta da ::1: durata<1ms
Risposta da ::1: durata<1ms
Statistiche Ping per ::1:
Pacchetti: Trasmessi = 4, Ricevuti = 4, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 0ms, Massimo = 0ms, Medio = 0ms
>>
GC> call/output "E:\Installation de logiciel\REBOL\View 1.3 -
GC> Betas testing\rebview1224031.exe -s xcode.r" %results.txt
GC> print read
GC> %results.txt
REBOL does not send output to STDOUT on Windows, so CALL/OUTPUT on
REBOL itself isn't useful.
GC> As it currently stands I don't see the real usefulness of
GC> having a script like easy-vid.r or any other script that would
GC> lauch
GC> another REBOL script during some CLICK and PLAY demo app
GC> - as I planned it initially...
To launch another REBOL script there's LAUNCH.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[6/11] from: nitsch-lists:netcologne at: 12-Jan-2004 16:27
Am Montag 12 Januar 2004 11:52 schrieb Gabriele Santilli:
> Hi Gerard,
>
> REBOL does not send output to STDOUT on Windows, so CALL/OUTPUT on
> REBOL itself isn't useful.
>
How about [ call/output "rebol --cgi script.r" ] ? should write to output?
> Regards,
> Gabriele.
-Volker
[7/11] from: g:santilli:tiscalinet:it at: 12-Jan-2004 16:57
Hi Volker,
On Monday, January 12, 2004, 4:27:37 PM, you wrote:
VN> How about [ call/output "rebol --cgi script.r" ] ? should write to output?
Hmm, -c does not work in a MS-DOS window, but does with
CALL/OUTPUT. That's good to know. :-)
>> call/output {rebol.exe -c --do "print 'hello quit"} s: ""
== 0
>> print s
hello
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[8/11] from: gerardcote:sympatico:ca at: 12-Jan-2004 11:49
Hi Petr,
IIRC I already tested it and saw no difference. But I'll try the many suggestions Volker
offered me and I'll come back soon.
Thanks,
Gerard
[9/11] from: gerardcote:sympatico:ca at: 12-Jan-2004 12:18
Hi Volker,
----- Original Message -----
Volker Wrote:
> > call/output "E:\Installation de logiciel\REBOL\View 1.3 - Betas
> > testing\rebview1224031.exe -s xcode.r" %results.txt print read %results.txt
<<quoted lines omitted: 3>>
> in your example i expect "E:\Installation" is called with the rest as
> argument.
I will look at but seems the exec worked fine and the results correctly displayed
on the console. Seems the output has something to do with the mystery - and a
few seconds ago I received the reason from Gabriele. See its answer by yourself.
Clearly it is erroneous for me to think that CALLING a copy of REBOL ensures
the output of the running script is also redirected since REBOL normally doesn't
send its output to STDOUT. This is a misconception I had about the way I
planned my solution as it is often the case.
I simply skipped the fact that this is the second copy of REBOL that must be
redirected and not only the first one...
Thank you,
Gerard
P.S. I will nevertheless try your suggestions just to see the effects I can get from
them
even if I don't hope to receive the results in a file as planned working in this direction.
[10/11] from: gerardcote:sympatico:ca at: 12-Jan-2004 12:27
Hi Gabriele,
Gabriele wrote:
==========
> GC> 2. The Call/output doesn't seem to create and fill the
> GC> expected file with the results outputted when used - an empty
<<quoted lines omitted: 5>>
> == 0
> >> print s
Thanks for demonstrating this way of doing things.
I will be VERY useful to many of us I think.
> GC> call/output "E:\Installation de logiciel\REBOL\View 1.3 -
> GC> Betas testing\rebview1224031.exe -s xcode.r" %results.txt
> GC> print read
> GC> %results.txt
>
> REBOL does not send output to STDOUT on Windows, so CALL/OUTPUT on
> REBOL itself isn't useful.
>
AH! AH! This is the real reason I presume. Seems I misconceived the way it would work
as
I skipped the fact that the CALL would redirect all the outputted output even
the results coming from the newly called copy of REBOL.
I could have done better but sometimes evidence is in front of our face without
our eyes seeing it. An old "déjà vu" pattern that still survives... many many years!
Thanks for this one. Now at least I know that I was looking for is not feasible in the
way
hoped to do so.I
> GC> As it currently stands I don't see the real usefulness of
> GC> having a script like easy-vid.r or any other script that would
> GC> lauch
> GC> another REBOL script during some CLICK and PLAY demo app
> GC> - as I planned it initially...
>
> To launch another REBOL script there's LAUNCH.
>
Thanks. I'll throw an eye on it too. May be it could have been shorter than
learning to use the CALL mechanism. But as I don't know the details I will
not speculate here. I'll first go and learn more.
Regards,
Gerard
[11/11] from: gerardcote:sympatico:ca at: 12-Jan-2004 14:27
Hi Volker and Gabriele,
for your help.
I'll try to experiment with that too in my own context !
Regards,
Gerard
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted