Reading Output from Shell Command

  • Thread starter Thread starter Kevin Mansel via .NET 247
  • Start date Start date
K

Kevin Mansel via .NET 247

Ok, basically this is my problem. I'm building a console app tocall a dos program. So i'm using the Shell command to call theprogram, now depending on what happens, I want to read theoutput that this program returns. I'm just missing the stepshere. I know that I can set the Shell command to an integer,but this only returns a 0 to me telling me that it executed, notwhat is being returned to the console by that application. Isthere a way to find out this information?

Thanks!
 
April 7, 2005

You have to set the Process.Startinfo.RedirectStandardOutput property. You
can then access the Process.StandardOutput to retrieve a Streamreader that
has the output....

dim p as new process
p.startinfo.filename = "..."
p.startinfo.redirectstandardoutput = true
p.start
dim reader as new streamreader = p.standardoutput
messagebox.show(reader.readtoend)

Hope this helps! :-)

Joseph MCAD
 
LOL! For the past few months, I've been developing a VB.NET app that acts as
a front end to several PERL apps. I use the shell command (in a thread) to
start a PERL app and in one command pass all of the command line arguments
(values from Textboxes, comboboxes, etc.) to the PERL App.

Then, using the sledgehammer approach, I setup a TCPListener in a thread to
read the output from the perl app(Of course, I had to add the TCPClient
functionality to all of my PERL apps!!)

For some reason, I just never thought about simply redirecting the output of
the command window itself.

I'll have to make a small test app to see if redirecting the output (as you
stated) works as well as the TCPListener/TCPclient setup.

In some of my initial attempts at controlling the PERL app from a VB App, I
noticed that SendKeys does not work if the command window is hidden. Will
redirecting the output work if the command window is hidden?

regards,
Lee

Joseph MCAD said:
April 7, 2005

You have to set the Process.Startinfo.RedirectStandardOutput property.
You can then access the Process.StandardOutput to retrieve a Streamreader
that has the output....

dim p as new process
p.startinfo.filename = "..."
p.startinfo.redirectstandardoutput = true
p.start
dim reader as new streamreader = p.standardoutput
messagebox.show(reader.readtoend)

Hope this helps! :-)

Joseph MCAD
 
April 7, 2005

I think you are asking whether redirecting the output will still work if
you specify for the black window to not show up visible. If so, the answer
is yes. To not make the window show use...

p.Startinfo.UseShellExecute = false
p.startinfo.createnowindow = true

I forgot to mention to call p.WaitForExit before showing the output or
closing the output stream reader. So...

p.Start
dim reader as streamreader = p.standardoutput
p.waitforexit
messagebox.show(reader.readtoend)

In case you don't know you specify the parameters to the .exe using the
arguments property...

p.filename = "....exe"
p.Arguments = "-n -r /e flags"

Glad to hear this helped!

Joseph MCAD



lgbjr said:
LOL! For the past few months, I've been developing a VB.NET app that acts
as a front end to several PERL apps. I use the shell command (in a thread)
to start a PERL app and in one command pass all of the command line
arguments (values from Textboxes, comboboxes, etc.) to the PERL App.

Then, using the sledgehammer approach, I setup a TCPListener in a thread
to read the output from the perl app(Of course, I had to add the TCPClient
functionality to all of my PERL apps!!)

For some reason, I just never thought about simply redirecting the output
of the command window itself.

I'll have to make a small test app to see if redirecting the output (as
you stated) works as well as the TCPListener/TCPclient setup.

In some of my initial attempts at controlling the PERL app from a VB App,
I noticed that SendKeys does not work if the command window is hidden.
Will redirecting the output work if the command window is hidden?

regards,
Lee
 
Joseph,

Understood. while I have your attention, I think I'll pick your brain a bit,
if that's ok. Before I start creating test apps and possible changing my
main app, let me tell you a bit about what the app does, and see if you
think switching to a redirect and streamreader is the way to go.

1. There are six different PERL apps that are controlled by the VB app, plus
some other funtionality in the VB app. And, each of the PERL apps is run in
a seperate thread, so all apps can be run simultaneously if desired. Some of
the PERL apps can take up to an hour to run depending on the amount of input
data.

2. When the TCPListener receives a string, it passes it to a function that
uses several regex expressions to determine where the string should be
displayed in the VB form. Most of the strings are sequentially added to a
listbox. some of the strings are used to trigger progress on a progress bar,
and some of the strings go to different labels telling the user more
specifically what tasks are actually being completed as the PERL app runs.

3. Occasionally, due to faulty input data, the PERL app will die, and in
this case the last string that is passed to the Listener provides
information regarding the error cause. In this case, the VB app terminates
the PERL process and informs the user of the specific error. another
complication to this part is that some of the PERL apps use OLE to write
data to an Excel spreadsheet. If the PERL app dies, I clean up not only the
PERL app, but the Excel process as well.

So, based on this, do you think I can just pass the streamreader output to
my regex function? Do you think that there is any speed or stability
difference between using a socket to transfer the data rather than the
streamreader?

TIA
Lee
 
April 8, 2005

First, I don't know anything about Perl. Second, you can definitely pass
the streamreader output to the regex function, BUT you have to make sure
that the output has come back from the program before you do so. If the
string comes from the output, say about in 1/2 hour, then you might have to
continue to test whether the output you need has come back yet. As far as a
difference in performance, my view is that with sockets you are actually
sending data through a network (even if it is just on the same machine) and
therefore negiotiating connections possibly. Therefore I think it is much
better to do it with streamreaders that don't go over a network. Even if
there is no negiotiating, your program is still having to open ports,
connect, send responses back and forth... This is just my opinion and I
like having my brain picked! :-)

Joseph MCAD
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Back
Top