Command/Pro call interact with external program using STDIO
[1/10] from: micael:gullmes:telenor:se at: 29-Jan-2003 11:01
Hi list,
has anyone done a nice solution for interacting with external programs multiple times
using call and STDIO?
What I need to achieve is to
1. start an external program
2. send data throught STDIO as input to the external program
3. retrieve the result from STDIO
4. send data throught STDIO as more input to the external program
5. retrieve the result from STDIO4.
6. And so forth until all is done, then I send a ctrl-c to stop the external program.
Example:
----------------------
call "format a:"
Insert new diskette for drive A: and press ENTER when ready... <---- send newline
Checking existing disk format. Formatting 1.44M Format complete.
Volume label (11 characters, ENTER for none)? <---- send "volume x"
1,457,664 bytes total disk space 1,457,664 bytes available on disk
512 bytes in each allocation unit. 2,847 allocation units available.
Volume Serial Number is 1E27-16DA
Format another (Y/N)? <---- send "N"
--------------------------
Is there anyone that has a solution for sending info to the external program from rebol?
Brgds /Micael
[2/10] from: bry:itnisk at: 29-Jan-2003 11:42
>has anyone done a nice solution for interacting with external programs
>multiple times using call and STDIO?
Okay, I was thinking about this, along with some other subjects in a
document I've been calling experiments for integrating Rebol with
Windows, anyway here is the section on STIO I was going to post:
Std.r
Rebol[Title "reb-wscript experiments"]
test: "c:\winnt\system32\cscript.exe domainname.vbs"
call/output test %output.txt
test: read %output.txt
parse test[thru "reserved." copy text to end]
test: trim text
write %output.txt test
do %output.txt
domainname.vbs
dim wmi, textout
Set wmi = GetObject("winmgmts:").InstancesOf ("Win32_ComputerSystem")
textout= "Rebol[]" & vbcrlf & "Domains: "
for each System in wmi
textout= textout & "[DomainName " & System.Domain & "]"
next
WScript.StdOut.Write(textout)
This is a bad example, was going to rework it so that domainname.vbs
wrote out an object.
Here's the pertinent text from the larger document:
Thirdly there is the possibility of accessing external libraries via
rebol if one has Rebol/view pro and other more feature rich versions,
this is as I understand also available in the sdk version. I must admit
that I don't like this too much, maybe it is because I haven't seen a
lot of examples yet, just the tutorial on RT but working with libraries
in this way seems bulky.
It seems to me that there should be an interim methodology, that of
returning objects etc. as Stdout of command line calls.
Of course I am probably thinking along these lines mainly because for me
Rebol is most likely to be used for short hacks, mainly due to structure
of licensing agreement.
However, as the example of std.r and domainname.vbs shows, it is
feasible.
There are a number of large areas of Windows information that could be
accessed via a standard library of scripts that I suppose would do
nothing more than write very simple objects to Rebol.
Of course one could always just do one's own, but I think it might be a
better idea to build some common ones. For example a WMI one, an ADSI
one.
These little Rebol/Wscript libraries should probably have a common
dialect, haven't given much thought to what it should do, preferring to
open discussion on the matter, although one thing I suppose would be to
allow a script to either do the rebol script, or generate the rebol
script by calling wscript and then do the script.
For obvious performance reasons.
This isn't exactly what you were looking for, rather it is a suggestion
for building what you were looking for, with hoped for input, comments
etc.
[3/10] from: micael:gullmes:telenor:se at: 29-Jan-2003 14:41
Hi,
thanks for the repsonse, as you say, it is not exactly what I am looking for.
I've been playing with another way of doing it using Solaris and inetd server/daemon,
in that wat I start the external program with rebol by opening a port specified in inetd.
But it seems like overkill to port communication and a server/daemon for this...
I really would like a simple solution, "the rebol way", similar to opening a port.
;-------Fantasy example 1
stdio: open/call %"format a:"
if equal? copy stdio "Insert new diskette for drive A: and press ENTER when ready..."
[
insert stdio "Y"
]
print result: copy stdio
close stdio
;-------End Fantasy example 1
Brgds /Micael
-----Ursprungligt meddelande-----
Fr=E5n: bryan [mailto:[bry--itnisk--com]]
Skickat: den 29 januari 2003 11:43
Till: [rebol-list--rebol--com]
=C4mne: [REBOL] Re: Command/Pro call interact with external program using
STDIO
>has anyone done a nice solution for interacting with external programs
>multiple times using call and STDIO?
Okay, I was thinking about this, along with some other subjects in a
document I've been calling experiments for integrating Rebol with
Windows, anyway here is the section on STIO I was going to post:
Std.r
Rebol[Title "reb-wscript experiments"]
test: "c:\winnt\system32\cscript.exe domainname.vbs"
call/output test %output.txt
test: read %output.txt
parse test[thru "reserved." copy text to end]
test: trim text
write %output.txt test
do %output.txt
domainname.vbs
dim wmi, textout
Set wmi = GetObject("winmgmts:").InstancesOf ("Win32_ComputerSystem")
textout= "Rebol[]" & vbcrlf & "Domains: "
for each System in wmi
textout= textout & "[DomainName " & System.Domain & "]"
next
WScript.StdOut.Write(textout)
This is a bad example, was going to rework it so that domainname.vbs
wrote out an object.
Here's the pertinent text from the larger document:
Thirdly there is the possibility of accessing external libraries via
rebol if one has Rebol/view pro and other more feature rich versions,
this is as I understand also available in the sdk version. I must admit
that I don't like this too much, maybe it is because I haven't seen a
lot of examples yet, just the tutorial on RT but working with libraries
in this way seems bulky.
It seems to me that there should be an interim methodology, that of
returning objects etc. as Stdout of command line calls.
Of course I am probably thinking along these lines mainly because for me
Rebol is most likely to be used for short hacks, mainly due to structure
of licensing agreement.
However, as the example of std.r and domainname.vbs shows, it is
feasible.
There are a number of large areas of Windows information that could be
accessed via a standard library of scripts that I suppose would do
nothing more than write very simple objects to Rebol.
Of course one could always just do one's own, but I think it might be a
better idea to build some common ones. For example a WMI one, an ADSI
one.
These little Rebol/Wscript libraries should probably have a common
dialect, haven't given much thought to what it should do, preferring to
open discussion on the matter, although one thing I suppose would be to
allow a script to either do the rebol script, or generate the rebol
script by calling wscript and then do the script.
For obvious performance reasons.
This isn't exactly what you were looking for, rather it is a suggestion
for building what you were looking for, with hoped for input, comments
etc.
[4/10] from: mmastroianni:lepcorp at: 29-Jan-2003 9:56
Hi all -
Just my 2c from a REBOL newbie:
I think working out an elegant
(read "simple, direct") solution
managing STDIO issues (at least w/
/Command) would greatly accelerate
the adoption of REBOL in a wide
variety of business environments.
I find myself constantly dropping
back to use awk scripts in various
piped configurations to get jobs
done quickly, when I really feel
likeI could do so much more w/
REBOL in the big picture. No doubt
much of this is learning curve,
but old habits die hard, and the
work does have to get done *now*.
Anything that makes REBOL less
effort than older, more established
scripting languages for basic tasks
(which, on balance REBOL does very well)
allows for quicker, deeper adoption,
IMHO... If I can freely mix/match
REBOL with Unix shell / PERL / AWK / Python etc.,
scripts, I can do so selectively, obsoleting
old code according to available time --
and therefore I would do so ...
Just my 2c -
Mike
[5/10] from: bry:itnisk at: 29-Jan-2003 16:13
>I've been playing with another way of doing it using Solaris and inetd
>server/daemon,
>in that wat I start the external program with rebol by opening a port
>specified in inetd.
>But it seems like overkill to port communication and a server/daemon
for >this...
well the std.r would work I suppose with any other scripting language
available from the command line, no matter the platform, this was one of
the things I was hoping to get some interest in.
The port thing seems to me as a way to connect with external programs
that are not accessible via the command line. A propos that I was doing
some stuff on a separate (personal) project to make Rebol talk with
erlang via opening a port.
[6/10] from: jeperk:swbell at: 29-Jan-2003 10:08
Hello all,
To introduce myself, my name is John Perkins. I just bought both SDK's
and joind the list yesterday.
I was failing at this yestersay and I really hoped it was just my lack
of REBOL skills.
I was expecting a bit different functionality in this area. The
documentation seems to say that piping is functional, however I'm not
seeing it either.
I hoped that the call/output function could be used for monitoring a
program that constantly spews output.
Instead, this seems to ack like call/wait with no way to continue since
the output never stops.
The other odddity is that you have to use "/" instead of "\" in paths
passed as an arg in a Windows exe call.
Are we missing something similar on call/output and call/input?
Thanks,
John Perkins
Michael J. Mastroianni wrote:
[7/10] from: g:santilli:tiscalinet:it at: 29-Jan-2003 21:44
Hi Gullmes,
On Wednesday, January 29, 2003, 2:41:12 PM, you wrote:
GM> ;-------Fantasy example 1
GM> stdio: open/call %"format a:"
GM> if equal? copy stdio "Insert new diskette for drive A: and press ENTER when ready..."
[
GM> insert stdio "Y"
GM> ]
GM> print result: copy stdio
GM> close stdio
GM> ;-------End Fantasy example 1
Actually REBOL allows you to do something very close to that. CALL
allows you to pass a port for the /INPUT and /OUTPUT refinements.
You could write your own port handler to have the functionality
you desire. I cannot guarantee that it will work because I know
there are some problems if the way CALL handles IO redirection,
but in theory it should work. :-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[8/10] from: micael:gullmes:telenor:se at: 30-Jan-2003 9:31
Hi Gabriele,
if it works, that would be a neat solution!
Unfortenatly I do not have the time to dig into it rigth now,
I have a tight deadline for the project I am working with.
I will work around it in a quick'n'dirty & more CPU/memory consuming way.
I.e. calling the external program multiple times, not a nice solution, but time is my
enemy here.
I hope I get some sparetime to start looking into this ata later stage, but since my
knowledge about ports are limited, it will probably take lots of time.
Brgds /Micael
-----Ursprungligt meddelande-----
Fr=E5n: Gabriele Santilli [mailto:[g--santilli--tiscalinet--it]]
Skickat: den 29 januari 2003 21:45
Till: Gullmes Micael
=C4mne: [REBOL] Re: Command/Pro call interact with external program using
STDIO
Hi Gullmes,
On Wednesday, January 29, 2003, 2:41:12 PM, you wrote:
GM> ;-------Fantasy example 1
GM> stdio: open/call %"format a:"
GM> if equal? copy stdio "Insert new diskette for drive A: and press ENTER when ready..."
[
GM> insert stdio "Y"
GM> ]
GM> print result: copy stdio
GM> close stdio
GM> ;-------End Fantasy example 1
Actually REBOL allows you to do something very close to that. CALL
allows you to pass a port for the /INPUT and /OUTPUT refinements.
You could write your own port handler to have the functionality
you desire. I cannot guarantee that it will work because I know
there are some problems if the way CALL handles IO redirection,
but in theory it should work. :-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[9/10] from: anton:lexicon at: 30-Jan-2003 21:58
Before you give up, try this:
call/console "pause"
Anton.
[10/10] from: micael::gullmes::telenor::se at: 30-Jan-2003 15:34
Anton,
call/console "pause"
locks up rebol and waits for you to manually press a key.
It does not allow the rebol script to retrieve and send data interactivly to the external
program.
Brgds /Micael
-----Ursprungligt meddelande-----
Fr=E5n: Anton [mailto:[anton--lexicon--net]]
Skickat: den 30 januari 2003 11:58
Till: [rebol-list--rebol--com]
=C4mne: [REBOL] Re: Command/Pro call interact with external program using
STDIO
Before you give up, try this:
call/console "pause"
Anton.