"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
news
p.tqdkfvmb8jd0ej@petes-computer.local...
> On Fri, 06 Apr 2007 10:11:42 -0700, Jon Davis
> <jon@REMOVE.ME.PLEASE.jondavis.net> wrote:
>
>> Lots of people have PowerShell, it's a Windows Update piece.
>>
>> Just swap out PowerShell for CMD.exe:
>
> I don't know what you mean by "Windows Update piece". I have Windows
> Update, use it all the time, but don't have PowerShell installed.
>
> In any case, thank you for the sample code. On my computer, it runs just
> fine as long as I remove the extra ReadLine you've got (the one commented
> "command entry (echo)").
>
> For what it's worth, all I did was break in the debugger when the program
> got blocked, and saw that it was waiting at that line which showed that
> you never got to the point of writing to the input stream, meaning you
> were reading too many "discardable" lines up front.
I added them one by one as I read the ReadLine() which returned:
- two lines of the logo
- an empty line
- the echo of my "echo" command, BEFORE it gets executed.
Are you sure that what you commented out is not the command itself being
echoed rather than the execution of the ECHO command? Perhaps we have
different versions.
> Of course, one of the things this exercise illustrates is the fragility of
> the approach you're using. Even if it works fine now (as it does on my
> computer...can't say whether that's true on yours), you're tied to a
> precise sequence of lines of input and output.
Understood, but while generally such an interface would be useless as a
generic console app solution I do have some precise sequences in mind, or as
in the case of Tidy and some other EXEs I'm dealing with a constant of
either input one command and get back one line of output (ReadLine()), input
one command and get back several lines of results (ReadToEnd()), or input
multiple lines as a single input and read back the output. I am not dealing
with processes that have a dialogue of more than one input or more than one
string of output.
> ... beware. Many pitfalls lie ahead.
Totally. I would still like to build out my process wrappers described above
and I'm still not fully understanding what I'm missing.
Jon