By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,827 Members | 813 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,827 IT Pros & Developers. It's quick & easy.

Reading Output from Shell Command

P: n/a
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!

--------------------------------
From: Kevin Mansel

-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)

<Id>HMrdIkohokioRR4woWbZSQ==</Id>
Nov 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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" <an*******@microsoft.discussions.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ee**************@TK2MSFTNGP15.phx.gbl...
"Kevin Mansel via .NET 247" <an*******@dotnet247.com> schrieb:
Ok, basically this is my problem. I'm building a console app to call a
dos program. So i'm using the Shell command to call the program, now
depending on what happens, I want to read the output that this program
returns.


<URL:http://dotnet.mvps.org/dotnet/samples/misc/RedirectConsole.zip>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Nov 21 '05 #2

P: n/a
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" <lg***@online.nospam> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
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" <an*******@microsoft.discussions.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ee**************@TK2MSFTNGP15.phx.gbl...
"Kevin Mansel via .NET 247" <an*******@dotnet247.com> schrieb:
Ok, basically this is my problem. I'm building a console app to call a
dos program. So i'm using the Shell command to call the program, now
depending on what happens, I want to read the output that this program
returns.

<URL:http://dotnet.mvps.org/dotnet/samples/misc/RedirectConsole.zip>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>



Nov 21 '05 #3

P: n/a
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


"Joseph MCAD" <an*******@microsoft.discussions.com> wrote in message
news:ue**************@TK2MSFTNGP09.phx.gbl...
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" <lg***@online.nospam> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
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" <an*******@microsoft.discussions.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ee**************@TK2MSFTNGP15.phx.gbl...
"Kevin Mansel via .NET 247" <an*******@dotnet247.com> schrieb:
>Ok, basically this is my problem. I'm building a console app to call a
>dos program. So i'm using the Shell command to call the program, now
>depending on what happens, I want to read the output that this program
>returns.

<URL:http://dotnet.mvps.org/dotnet/samples/misc/RedirectConsole.zip>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>



Nov 21 '05 #4

P: n/a
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


"lgbjr" <lg***@online.nospam> wrote in message
news:OI*************@TK2MSFTNGP15.phx.gbl...
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


"Joseph MCAD" <an*******@microsoft.discussions.com> wrote in message
news:ue**************@TK2MSFTNGP09.phx.gbl...
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" <lg***@online.nospam> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
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" <an*******@microsoft.discussions.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ee**************@TK2MSFTNGP15.phx.gbl...
> "Kevin Mansel via .NET 247" <an*******@dotnet247.com> schrieb:
>>Ok, basically this is my problem. I'm building a console app to call a
>>dos program. So i'm using the Shell command to call the program, now
>>depending on what happens, I want to read the output that this program
>>returns.
>
> <URL:http://dotnet.mvps.org/dotnet/samples/misc/RedirectConsole.zip>
>
> --
> M S Herfried K. Wagner
> M V P <URL:http://dotnet.mvps.org/>
> V B <URL:http://classicvb.org/petition/>



Nov 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.