Is there any way to capture console program output using a script? For example, execute a "dir", capture its output, and then process it in the script...
Linking Console Programs to MUClient
Posted by Poromenos on Thu 15 May 2003 03:02 PM — 13 posts, 29,816 views.
If its just the dir, you can use a FSO to get the contents of the directory.
That was an example :p
You would need to redirect stdout - I don't know if this can be done in a script. Can you post an example and I'll try to do it.
I wanted to use a chess engine to make a chess script, and the chess engine is a DOS program (Crafty). You can find crafty all over the net, just search "crafty chess" on google :) But if you just want to experiment, I suppose that any program that remains running when you open it and waits for your input will do...
"waits for your input"? Do you want to capture input or output?
My bad :) Actually, I want to interface it with my script... I want to be able to see what it outputs and then enter input to it... Is that possible?
Sounds dubious, but probably possible if you somehow pipe the commands you type into MUSHclient into its input stream. Not sure exactly how you would do that. It would involve input redirection of some sort. This isn't really a MUSHclient query as such, but a Windows scripting one. Try searching the Net for an answer for doing that in VBscript in general.
Grr.. Accidently hit a close window command while typing the last reply to this. :p Sigh...
So here we go again..
One option I can think of is to find some version of Command.com or similar 'shell' as source code and convert it to a COM application. You basically still run it as a console app, but you have it internally redirect the input and output to Mushclient. Like:
i = createobject("MyCom.com")
i.SetWorld(GetWorld)
' Optionally you could allow the following to also be
' set to ("Note") and have it display in the output window.
' This would require function overloading, which Nick
' doesn't seem to like, but it should work. ;)
i.DirectOutputTo("Plugin",GetPluginID,"MyInput")
i.Execute("C:\DOS Programs\MyApp.exe")
Then depending on if you used the "Note" or "Plugin" directive you could have the script handle all the input like:
or you could use an alias that sent what you typed into the input box in Mushclient to respond if you used the "Note" version.
Of course this is all theory, but may be workable. The alternative, would be to design a TSR that loads first. In both cases you would run it using the normal ShellExecute trick. Both would run under the normal Command.com (or COM.COM on XP I think??). The TSR would provide the same COM to Keyboard interface, but also redirect something unused like LPT2: or LPT3: to the COM interface going back the other direction. This 'might' be easier, except that you run into the problem how exactly in either case you create a COM based TSR or shell that will do this. I am afraid the best I can manage is theory, but I wouldn't mind seeing someone design something that would do this. ;)
So here we go again..
One option I can think of is to find some version of Command.com or similar 'shell' as source code and convert it to a COM application. You basically still run it as a console app, but you have it internally redirect the input and output to Mushclient. Like:
i = createobject("MyCom.com")
i.SetWorld(GetWorld)
' Optionally you could allow the following to also be
' set to ("Note") and have it display in the output window.
' This would require function overloading, which Nick
' doesn't seem to like, but it should work. ;)
i.DirectOutputTo("Plugin",GetPluginID,"MyInput")
i.Execute("C:\DOS Programs\MyApp.exe")
Then depending on if you used the "Note" or "Plugin" directive you could have the script handle all the input like:
dim Stream
sub MyInput(IStream)
if IStream <> chr(13) then
Stream = Stream + IStream
else
select case Stream
case "What is your name?"
i.Input "Fred"
case ...
end select
Stream = ""
end if
end sub
or you could use an alias that sent what you typed into the input box in Mushclient to respond if you used the "Note" version.
Of course this is all theory, but may be workable. The alternative, would be to design a TSR that loads first. In both cases you would run it using the normal ShellExecute trick. Both would run under the normal Command.com (or COM.COM on XP I think??). The TSR would provide the same COM to Keyboard interface, but also redirect something unused like LPT2: or LPT3: to the COM interface going back the other direction. This 'might' be easier, except that you run into the problem how exactly in either case you create a COM based TSR or shell that will do this. I am afraid the best I can manage is theory, but I wouldn't mind seeing someone design something that would do this. ;)
You're right, Shadowfyr, this would work... Actually, i found some ActiveX controls that allow you to interface with console apps, and i'll try designing an activex program to do it... It shouldn't be very hard...
Also, can you remind me how to use ShellExecute from VBScript?
And, on another note, a problem i currently have is that i can't get ActiveX controls to call script functions. That would be necessary if i was to write an ActiveX component, since I wouldn't have any other way of checking for input, apart from polling, which is not exactly effective... Does anyone know how to do that?
By the way, it's "cmd.com" on xp :)
Also, can you remind me how to use ShellExecute from VBScript?
And, on another note, a problem i currently have is that i can't get ActiveX controls to call script functions. That would be necessary if i was to write an ActiveX component, since I wouldn't have any other way of checking for input, apart from polling, which is not exactly effective... Does anyone know how to do that?
By the way, it's "cmd.com" on xp :)
> Also, can you remind me how to use ShellExecute from VBScript?
I have no idea. I have never tried it.
As for calling script functions. That should be a simple matter of linking the table file for Mushclient's internals into your program. However, I haven't tried doing that either, so other than the simple example given by Nick or talking to the guy that made the HUD map thing for a Battletech based mud, I don't know what to tell you.
Where did you find the ActiveX console controls BTW? Might be interesting to take a look at.
I have no idea. I have never tried it.
As for calling script functions. That should be a simple matter of linking the table file for Mushclient's internals into your program. However, I haven't tried doing that either, so other than the simple example given by Nick or talking to the guy that made the HUD map thing for a Battletech based mud, I don't know what to tell you.
Where did you find the ActiveX console controls BTW? Might be interesting to take a look at.
Hmm, good question :) Let me see if i can find the URL... A google search should fetch good results.. There should be something in my browser history...
(5 minutes later)
Here it is:
http://www.codeproject.com/atl/redirect.asp
(5 minutes later)
Here it is:
http://www.codeproject.com/atl/redirect.asp
Cool. This is potentially even better than what I described. Wonder if it works when you use 4DOS instead of command.com or cmd.com. The Windows/DOS command interpreter has always sucked imho and like with most stuff, if I ever manage to scrape the cash together, I plan to scrap the MS interpreter for something better. ;)
I mean what kind of real OS needs you to load a seperate TSR in order to support command histories, can't color code file types and uses 'type' to read file contents instead of a scrollable interface? Among other things I hated about MSDOS. lol
I mean what kind of real OS needs you to load a seperate TSR in order to support command histories, can't color code file types and uses 'type' to read file contents instead of a scrollable interface? Among other things I hated about MSDOS. lol