0

I was trying to start a exe with arguments by Process.Start. My first try is using Process.Start("Path/of/the/exe", "arguments of exe"). Here's my code snippets:

Process.Start(@"D:\Program Files\ITASCA\UDEC700\Exe64\udecConsole2017.exe", @"call 'D:\Work\202205\20220525\tunnel-for-cmd.txt'");

However the initialization of this exe is a bit slow, and the result is, I can only start the exe but the failed passing arguments. The following is the screenshot: enter image description here which is exactly the same result that starts without arguments.

By referencing this post C# - Making a Process.Start wait until the process has start-up, I changed my code as follows:

var process = Process.Start(@"D:\Program Files\ITASCA\UDEC700\Exe64\udecConsole2017.exe", @"call 'D:\Work\202205\20220525\tunnel-for-cmd.txt'");

while (string.IsNullOrEmpty(process.MainWindowTitle))
{
       System.Threading.Thread.Sleep(100);
       process.Refresh();
}

however these changes does not work.

I think my goal is to wait until exe completely started and then run it with arguments, but I dont know how to implement this.

=====================================================

New additions: if I type in arguments call 'D:\Work\202205\20220525\tunnel-for-cmd.txt' in this started process, I will get my result: enter image description here SO I think the input arguments should be OK?

======================================= new addition 2:

code for checking outputstream end enter image description here

Lake_Lagunita
  • 521
  • 1
  • 4
  • 20
  • I don't think thats a problem of the calling side, if you have the called programm in access you can store or pass the args till they are needed (after the initialization) – Leppin Jun 29 '22 at 14:54
  • The time the process takes to start and passing the arguments should be unrelated. Maybe the issues is the formatting/quoting of the parameter. – 001 Jun 29 '22 at 14:54
  • 1
    `However the initialization of this exe is a bit slow, and the result is, I can only start the exe but the failed passing arguments.` there's no such concept. Processes don't accept parameters after some kind of initialization. The OS starts an executable program by loading it in memory and calling `Main` with those parameters. After that it's entirely up to the process to use the parameters. The parameters you passed are weird though. First the word `call` followed by a quoted string, `'D:\Work\202205\20220525\tunnel-for-cmd.txt'`. Are you sure the application isn't returning an error? – Panagiotis Kanavos Jun 29 '22 at 15:03
  • The post you link to has nothing to do with *this* problem. That question asked how to wait until the child process exits. You can add a 10 hour wait, that won't affect how that *other* process behaves – Panagiotis Kanavos Jun 29 '22 at 15:05
  • @PanagiotisKanavos please refer to my newly added screenshot. the screenshot is the result of start the exe. and if I type in call 'D:\Work\202205\20220525\tunnel-for-cmd.txt' , it will get result. – Lake_Lagunita Jun 29 '22 at 15:10
  • What you posted has nothing to do with the question. You aren't running `udecConsole2017.exe` with arguments. You're running `udecConsole2017.exe` with no arguments at all, and after some time typing some strings to the console. Those aren't process arguments. If you execute `udecConsole2017.exe call 'D:\Work\202205\20220525\tunnel-for-cmd.txt'` in the console, would the application work or throw an error? – Panagiotis Kanavos Jun 29 '22 at 15:14
  • @Leppin I think you got my question, but I have no idea how to store/pass the args till they are needed. – Lake_Lagunita Jun 29 '22 at 15:17
  • It looks like you want to re-direct the stdin of that program. So you start the program with no args, wait, send the string `call ...` to the app. Is that correct? There are plenty of dupes around here for that: https://www.google.com/search?q=C%23+Process.Start+stdin+site:stackoverflow.com – 001 Jun 29 '22 at 15:17
  • If you want to send commands to the application after it starts, start the application *without arguments* with `var process=Process.Start(@"D:\Program Files\ITASCA\UDEC700\Exe64\udecConsole2017.exe");`and then use [Process.StandardInput](https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.standardinput?view=net-6.0) to send text to it, the same way you would in a console. – Panagiotis Kanavos Jun 29 '22 at 15:19
  • @JohnnyMopp yes. that is correct. I made a mistake. – Lake_Lagunita Jun 29 '22 at 15:19
  • @PanagiotisKanavos Yes, I made a mistake. – Lake_Lagunita Jun 29 '22 at 15:20

1 Answers1

0

It appears this is a console application and you are typing in the console after it starts. This typing is not arguments: Arguments are provided only when starting a new process and never change.

What you are doing is providing something to the standard input of the program. Console programs have three streams the OS provides (one input and two output). You need to redirect these to detect when the program has started and to provide the proper input.

Something like this:

// Start with stdio redirected
var psi = new ProcessStartInfo()
{
    UseShellExecute = false,
    FileName = @"your exe",
    RedirectStandardInput = true, 
    RedirectStandardOutput = true,
};
var p = System.Diagnostics.Process.Start(psi);

// Read until the udec> prompt
while(true)
{
    var line = p.StandardOutput.ReadLine();
    if(line.StartsWith("udec>"))
        break;
}

// Write the command
p.StandardInput.WriteLine(@"call 'D:\Work\202205\20220525\tunnel-for-cmd.txt'");

// Read the result
p.StandardOutput.ReadToEnd();
Dark Falcon
  • 43,592
  • 5
  • 83
  • 98
  • The code should be correct, but when I debug while loop, everything goes well and I can catch all output lines except "udec>":after catching the line " Precision: double", the program kept running without hitting the break point. – Lake_Lagunita Jun 29 '22 at 16:08
  • Then if I end the console by closing it, the break point is hit and I can see the value of line is "udec>" but then the program ends. – Lake_Lagunita Jun 29 '22 at 16:11
  • Because "udec>" probably doesn't have a newline after it. Same concept, but `ReadLine` might not be the right tool. You probably just want to call `Read` continouously, append anything read to a string, and check to see if the output ends with "udec>". – Dark Falcon Jun 29 '22 at 17:17
  • I tried to use Process p = System.Diagnostics.Process.Start(psi); string output = p.StandardOutput.ReadToEnd(); but the code still hang up at ReadToEnd() – Lake_Lagunita Jun 29 '22 at 17:21
  • Yes. The stream will remain open as long as the process is running. *You need to use `Read`.* Not `ReadLine` because the text you want does not end in a newline. Not `ReadToEnd` because it will not complete until the process has already exited. – Dark Falcon Jun 29 '22 at 17:43
  • I tried use " int v = p.StandardOutput.Read(); " to check if it reaches "udec>" by checking if v == 62 (as ascii code for '>'), and this is validated. then the code starts its last while loop, but when the code starts p.StandardOutput.Read() (as I expect the last read), it hangs up again. – Lake_Lagunita Jun 29 '22 at 17:51
  • I added the code in my original post for your reference. – Lake_Lagunita Jun 29 '22 at 18:00
  • Yes. When you find the `>` you need to STOP calling `Read`. You're ready to write your command, so simply `break` out of the read loop. – Dark Falcon Jun 30 '22 at 20:56
  • now that I can find the `>` and break out of the loop, but after I write the command by `p.StandardInput.WriteLine(@"call 'D:\Work\202205\20220525\tunnel-for-cmd.txt'")` I could read no output. Have tried other ways like using `OutputDataReceived` events but none of them works. – Lake_Lagunita Jul 01 '22 at 01:13
  • I have added a `p.Exited` event handler to check if the program exited. The program kept running without exit until I killed the program. – Lake_Lagunita Jul 01 '22 at 02:22
  • Did you also try calling `p.StandardInput.Flush()` to ensure the line you wrote is not being buffered? – Dark Falcon Jul 01 '22 at 16:16
  • Yes, I also called flush after calling writeline, – Lake_Lagunita Jul 04 '22 at 01:11