Develop Reference

Let the shell parse or do your own parsing (powershell/cmd)

I develop an application with command line parameters and use it in cmd shell and powershell. There it is obvious that the arguments are received differently in main() of my application.
static void Main(string[] args)
{
// In cmd shell: args[0] == "-ipaddress=127.0.0.1"
// In powershell: args[0] == "-ipaddress=127"
// and args[1] == ".0.0.1"
}
Example:
myApp.exe -ipaddress=127.0.0.1
In my C# application the arguments are interpreted differently depending on the shell I start the app in.
In cmd shell: arg[0]=-ipaddress=127.0.0.1
In powershell: arg[0]=-ipaddress=127 and arg[1]=.0.0.1
What is best practice here?
Should I join all args[] and parse the arguments in my application?
Should I rely on the shell's parser?

I would abandon cmd shell support completely and just created proper PowerShell cmdlet. Writing a Windows PowerShell Cmdlet. But I don't know your exact requirements.
In general calling executable from cmd and PowerShell should work same way. For example line, "> ping -n 3 google.com" just works fine no matter where you put it.

tl;dr:
When calling from PowerShell, enclose the entire argument in '...' (single quotes) to ensure that it is passed as-is:
myApp.exe '-ipaddress=127.0.0.1'
You've run into a parsing bug[1]
where PowerShell breaks an unquoted argument that starts with - in two at the first .
The following simplified example demonstrates that:
# Helper function that echoes all arguments.
function Out-Argument { $i = 0; $Args | % { 'arg[{0}]: {1}' -f ($i++), $_ }}
# Pass an unquoted argument that starts with "-" and has an embedded "."
Out-Argument -foo=bar.baz
The above yields:
arg[0]: -foo=bar
arg[1]: .baz
[1] The presumptive bug is present as of Windows PowerShell v5.1 / PowerShell Core v6.0.1 and has been reported on GitHub.
A PSv2 variation of the bug affects . when enclosed in "..." in the interior of the argument - see this answer of mine.

C# Process.Start: Whitespace Not Working Even Quoted

What I got:
Process.Start("cmd.exe", "/K \"C:/Program Files/nodejs/node.exe\" \"C:/rc/rainingchain/app.js\"");
Even though I wrapped the filename with escaped ", it still displays the error:
'C:/Program' is not recognized as an internal or external command, operable program or batch file.
What is wrong?

You need to use two " for spaces in program path:
Process.Start("cmd.exe", "/K \"\"C:/Program Files/nodejs/node.exe\" \"C:/rc/rainingchain/app.js\"\"");

You code will be translated to
cmd.exe /K "C:/Program Files/nodejs/node.exe" "C:/rc/rainingchain/app.js"
cmd.exe will translate it to
C:/Program Files/nodejs/node.exe" "C:/rc/rainingchain/app.js
That's why it complain errors.
What you need is to enclose whole node.exe command with double quote again.
Process.Start("cmd.exe", "/K \"\"C:/Program Files/nodejs/node.exe\" \"C:/rc/rainingchain/app.js\"\""); so the node.exe command will be "C:/Program Files/nodejs/node.exe" "C:/rc/rainingchain/app.js"
BTW, why don't just call node.exe directly?
Process.Start("C:/Program Files/nodejs/node.exe", "C:/rc/rainingchain/app.js");

How to view Process.Start() Arguments as they are passed to executable

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.

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();

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.

StartInfo.Arguments in c#

I found the following snippet of the code:
using System;
using System.Diagnostics;
public class RedirectingProcessOutput
{
public static void Main()
{
Process p = new Process();
p.StartInfo.FileName = "cmd.exe";
p.StartInfo.Arguments = "/c dir *.cs";
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.Start();
string output = p.StandardOutput.ReadToEnd();
p.WaitForExit();
Console.WriteLine("Output:");
Console.WriteLine(output);
}
}
but I can't figure out what this p.StartInfo.Arguments = "/c dir *.cs"; is doing? thanks in advance for any explanation

It's passing command line arguments to the process that will be launched.
In this particular case, the process is the Windows shell (cmd.exe). Passing a command line to it will cause it to execute this command when started; then, because of the /c parameter at the beginning it will terminate itself.
So the output of the process will be exactly what you will get if you open a command prompt and enter the command dir *.cs.

In the beginning was exec(3) and its friends, which accept the path to an executable and a variable length list of pointers to arguments. In sane operating systems, The process that gets started receives a point to the argument list, each word of which contains a pointer to and individual string. Sane shells parse the command line and populate the argument list required by exec(3).
You can see a direct correlation between the argument list accepted by exec(3):
exec ("some.executable.file", "arg1" , "arg2" , "arg3" , ... ) ;
and what gets passed to the entrypoint of the process:
int main ( char *arg[] ) { ... }
where argv[0] is the executable name, and argv[1]—argv[n-2] are the individual arguments, and argv[n-1] is a NULL pointer to indicate the end of the argument list.
Both conceptually simple and simple to implement.
CP/M didn't do it that way (I assume because of limited memory). It passed the started process the address of the raw command line from the shell and left its parsing up the process.
DOS followed in 1982 as clone of CP/M, handing a started process the address of the raw command line as well.
Windows hasn't deviated from that model since its inception. The Win32 CreateProcess() function
BOOL WINAPI CreateProcess(
__in_opt LPCTSTR lpApplicationName,
__inout_opt LPTSTR lpCommandLine,
...
);
still does the same thing, passing the raw command line to be passed to the program. The C runtime library, of course, takes care of the command line parsing for you...more or less.
So...in the CLR/.Net world, because of all this history, and because the CLR was designed to be dependent on the Win32 APIs, you have pass a complete command line to the process to be started. Why they didn't let you pass a params string[], instead and have the CLR build the command line is something that Microsoft's developers kept close to their chest.
Building the command line required by the started program is simple. You just join each argument into a single string with an SP character separating the arguments. Easy!
...until one of your arguments contains whitespace or a double quote character (").
Then you have to quote one or all of the arguments. Should be easy, but due to the bizarre quote rules, there are a lot of edge conditions that can trip you up.
A Windows command-line is broken up into words separated by whitespace, optionally quoted with double-quoted ("). Partly because Windows also got the path separater wrong (\ rather than /), the quoting rules are...byzantine. If you dig into the Windows CRT source code (the file is something like {VisualStudioInstallLocation}\VC\crt\src\stdargv.c), you'll find the command line parsing code.

That line just gives an argument to that proccess.

Running an exe from C# with arguments that have spaces in

I am scratching my head with this one. I am trying to run an exe from C# using system.diagnostics but it isnt passing over my arguments correctly so the exe falls over.
It splits the path after the word 'here' (see below) because of the space in it.
Does anyone know how I can get round this without renaming the directory (which isn't an option for me)
This works from command line:
"C:\Users\me\Desktop\myexternalexe\myexternalexe.exe" comments “\192.168.1.1\a\here is the problem\c\d\"
This doesn't from with in Visual Studio:
Process myexternalexe = new Process();
myexternalexe.StartInfo.FileName = #"C:\Users\me\Desktop\myexternalexe\myexternalexe.exe";
myexternalexe.StartInfo.Arguments = #"comments \\192.168.1.1\a\here is the problem\c\d\";
myexternalexe.Start();

But you've omitted the quotes from the C# version. It should be:
myexternalexe.StartInfo.Arguments = #"comments ""\\192.168.1.1\a\here is the problem\c\d\""";

Did you checked
this
In your case following should work.
string folderName = #"\\192.168.1.1\a\here is the problem\c\d\";
myexternalexe.StartInfo.Arguments= #"comments" + " \"" + folderName +"\"";

Have you tried:
alexe.StartInfo.Arguments = "comments \"\\\\192.168.1.1\\a\\here is the problem\\c\\d\\\"";