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

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.