1

I'm trying to run a fortran executable with Process.Start and it is not working. 

Process proc = new Process();
string args = "<C:\\file.in> C:\\file.out";
proc.StartInfo = new ProcessStartInfo(AppName, args);
proc.Start();

if I paste those arguments into a command window the application runs as expected. proc.Start() does not run as expected.

Any ideas how I can view what Start is actually passing as arguments? My gut feeling is that this is a quotes issue.

The executable launches and hangs, so I'm confident the AppName is getting passed in correctly, it looks like an argument problem.

I tried setting the WorkingDirectory to that of the input and output files as suggested in this question: process.start() arguments but that did not work.

Community
  • 1
  • 1
Eric
  • 1,392
  • 17
  • 37
  • are the '<' and '>' around C:\\file.in intentional? And are you using those on the command line? – SirPentor Jun 05 '12 at 22:42
  • Those are intentional and required and I am using those on the command line. Working with legacy fortran code is fun! – Eric Jun 05 '12 at 22:43
  • 5
    I'm pretty sure those aren't actually arguments then. '<' usually means "redirect standard input--use this file instead" and '>' means "redirect standard output--write to this file instead". Looks like your utility actually accepts input from stdin and writes to stdout. – SirPentor Jun 05 '12 at 22:45
  • 1
    Yep, that's how I see it, too. The DOS prompt is going to interpret the brackets as redirect symbols. `ProcessStartInfo` will not. – Robert Harvey Jun 05 '12 at 22:46
  • Assuming your using a 'special shell', as I'm not aware of a standard Windows cmd.exe/command.com supporting that syntax... You may have to find the *.exe that handles the C:\\File.in (fortran) format, and call that, passing it what it needs to process the file, etc. – JMC Jun 05 '12 at 22:47
  • The frustrating thing is I got this to work two years ago and now I can't find the code I used. Is there a way to run a straight up shell command instead of using Process.Start? I could write a little .bat file and run it. It doesn't have to be pretty :) – Eric Jun 05 '12 at 22:49
  • Why don't you setup your bat file and use this as ProcessStartInfo appname? – Steve Jun 05 '12 at 22:52
  • So, I just did a little test and App.exe file.out works just as well as App.exe file.out. so I'm not sure what the '<' and '>' mean. Probably redirects like you're saying, but it's hard for me to be sure because if I just launch the executable there is no console output, it's just a blind guess what I should input. – Eric Jun 05 '12 at 22:56
  • they are redirects... you will need to redirect those streams and handle it your self. – Yaur Jun 05 '12 at 23:14

2 Answers2

1

Redirection with the < and > command line operators is a feature that's implemented by the command line processor. Which is cmd.exe. Use its /c argument to execute just a single command:

string args = "/c " + AppName + " < C:\\file.in > C:\\file.out";
proc.StartInfo = new ProcessStartInfo("cmd.exe", args);
proc.Start();
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • I get the following: '/c' snot recognized as an internal or external command, operable program or batch file. – Eric Jun 06 '12 at 16:14
  • got it working with the following: `args = "/k \"" + AppName + "\" < " + inputFileName + " > " + outputFileName;` the /k keeps the console window open after running and was very helpful with debugging my args. – Eric Jun 06 '12 at 16:17
0

Your args string is exactly what is being passed as arguments to the executable. You can double check it reading your Process ProcessStartInfo.Arguments Property.

Something similar happened to me once, i.e., calling the executable from the command line worked and from code didn't, and it turned out that when called from the command line the executable was running on my PC's [C:] drive, and when called from code it was running on my PC's [E:] drive, which was full!

To check which directory your application is using to run the executable use the Directory.GetCurrentDirectory Method.

Thomas C. G. de Vilhena
  • 13,819
  • 3
  • 50
  • 44
  • I'm using full paths for the application name and for all arguments, so would it matter what the current directory is? – Eric Jun 06 '12 at 16:09
  • In my case it did because the executable I was running needed to create some temporary files and it was using the current directory to do that (instead of the [current user's temp folder](http://msdn.microsoft.com/en-us/library/system.io.path.gettemppath.aspx)), and since it was full the executable was failing to do what it was supposed to. – Thomas C. G. de Vilhena Jun 07 '12 at 18:30