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.
Related
I'm trying to make a call from one process to start another, supplying starting arguments as separate parameters in a ProcessStartInfo. The starting call uses a URL registered in Windows to find the second program, entered into FileName. I then add a string containing 4 parameters to Arguments. As I have understood it, the spaces in the string indicate the separation of the arguments.
Program 1
//Create starting information
System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo() {
FileName = "urlHandle:",
Arguments = "/argA valueA /argB valueB"
};
//Start second program
System.Diagnostics.Process.Start(startInfo);
Program 2
//Print received arguments to a file
Environment.GetCommandLineArgs().ToList().ForEach(a => writer.WriteLine(a + ",\t"));
The second program starts as intended (meaning the URL is working), but the output is incomplete.
[path to .exe of second program],
urlHandle:,
It contains the path to the program, the string set as FileName , but everything put into Arguments is missing.
Does anybody have any ideas why the arguments disappear?
Note 1: If I would add the arguments into the FileName, I would receive them as one string. In order to trigger the behaviour I want in the second program, I must supply it with several parameters instead of one. I know this is possible from testing it manually from the terminal.
Note 2: I'm using .Net Framework, so trying ArgumentList from .Net Core is not an option.
After some more tests I have found the issue. The error does not lie in how I set up and use ProcessStartInfo, but rather in that I am using a custom URL protocol.
In the Windows registry one defines the number of parameters that can be sent via the URL call ("C:\[path to my .exe]" "%1"). The first argument is the Filename, and is as such the only thing sent via the protocol. In order to send more, one is required to add "%2", "%3", etc.
Note: The path itself becomes argument 0 in the receiving program, while the actual sent parameters start at argument 1 and beyond.
I'm porting some C# code to Dart on Windows and just wasted a couple of hours on a frustrating difference in how Dart passes command line arguments through to the process.
Here's a portion of the C# code being ported, which executes just fine:
var startInfo = new ProcessStartInfo("C:\\Program Files\\Inkscape\\inkscape.exe", "--file=\"C:\\Users\\Kent\\test.svg\" --export-png=\"C:\\Users\\Kent\\test.png\" --export-width=100 --export-area-page")
{
UseShellExecute = false,
RedirectStandardOutput = true,
RedirectStandardError = true,
};
var process = Process.Start(startInfo);
process.WaitForExit();
if (process.ExitCode != 0)
{
var stdout = process.StandardOutput.ReadToEnd();
var stderr = process.StandardError.ReadToEnd();
Console.WriteLine(stdout);
Console.WriteLine(stderr);
}
Running this correctly produces an output PNG file. However, the Dart equivalent does not:
final inkscapeResult = await Process.run(
r'C:\Program Files\Inkscape\inkscape.exe',
[
'--file="C:\\Users\\Kent\\test.svg"',
'--export-png="C:\\Users\\Kent\\test.png"',
'--export-width=100',
'--export-area-page',
],
);
final exitCode = inkscapeResult.exitCode;
if (exitCode != 0) {
writeError(inkscapeResult.stdout);
writeError(inkscapeResult.stderr);
}
Instead, the process exits with code 1 and the program outputs:
** (inkscape.exe:5604): WARNING **: 17:30:09.785: Can't open file: "C:\Users\Kent\test.svg" (doesn't exist)
** (inkscape.exe:5604): WARNING **: 17:30:09.785: Can't open file: "C:\Users\Kent\test.svg" (doesn't exist)
** (inkscape.exe:5604): WARNING **: 17:30:09.785: Specified document "C:\Users\Kent\test.svg" cannot be opened (does not exist or not a valid SVG file)
It is pretty well-known that Inkscape is a bit finicky when it comes to executing on the command line, but the advice I've read is to simply pass in full paths, which I am doing.
I found that if I eschew arguments, it works:
final inkscapeResult = await Process.run(
r'C:\Program Files\Inkscape\inkscape.exe --file="C:\\Users\\Kent\\test.svg" --export-png="C:\\Users\\Kent\\test.png" --export-width=100 --export-area-page',
[],
);
So I inferred that Dart must be doing something with the arguments that Inkscape does not like. I managed to catch it in the act using Process Explorer and it has the following command line:
"C:\Program Files\Inkscape\inkscape.exe" "--file=\"C:\Users\Kent\test.svg\"" "--export-png=\"C:\Users\Kent\test.png\"" --export-width=100 --export-area-page
If I run this directly from the command line, I get no output but the image also does not get generated, so presumably it's failing in the same fashion. Compare this with the command line produced by the C# code:
"C:\Program Files\Inkscape\inkscape.exe" --file="C:\Users\Kent\test.svg" --export-png="C:\Users\Kent\test.png" --export-width=100 --export-area-page
Dart is wrapping each individual argument with quotes, where C# is not (though C#'s API does not even separate individual arguments). This is somehow breaking Inkscape's parser.
Who is in the wrong here? Me, Dart, C#, or Inkscape?
I think the simplest way is to split the argument name and the argument value like that:
final inkscapeResult = await Process.run(r'C:\Program Files\Inkscape\inkscape.exe', [
'--file', 'C:\\Users\\Kent\\test.svg',
'--export-png', 'C:\\Users\\Kent\\test.png',
'--export-width', '100',
'--export-area-page',
]);
That way you don't have to worry about escaping or quoting arguments.
I have a windows form application
Lets call it B
Now i have another application. Lets call it A
A will start B as a new process
Now i want to pass named parameter list to B and use them in B
How can i do that ?
What i mean is example parameter list
{job:"computer engineer",age:"32",experience:"3 years"}
Also these parameter list should be optional. Sometimes i may pass 5 parameters sometimes 0
And how will i read these parameters at start up on B application
So what is the way of doing this ? thank you
c#
Assuming you're calling your "B" process with Process.Start, the following should work:
System.Diagnostics.Process.Start(string fileName, string arguments)
And your "B" processes main thread should accept an array to house possible arguments that you can then iterate over.
static void Main(string[] args)
{
//your code to decipher arguments here
}
There are two ways I can think of doing this.
First is to use command line arguments. If you were to call you process (from the command line) as:
your.exe -job "computer engineer" -age 32 -experience "3 years"
You would then duplicate this in your code by settings the arguments in your process's start options. You would then have to set up your process to look for all of these flags, remembering that they can all be optional, and so on.
The second option (and this is a bit more flexible) is to make a file that holds the values you are passing over, and read it from your launched process. You could make this XML, or straight values.
Edit: here is an example of the first option
Process p = new Process();
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "your exe path";
startInfo.Arguments = "your argument list";
p.StartInfo = startInfo;
p.Start();
I don't want to tell you how to format your argument string; that should be up to you to decide. However, I will recommend a library to use that might make the parsing on the receiving end a bit easier.
I'm trying to run a command in cmd using C# and am having some difficulties. I'd like to be able to write the command to the cmd console so I can see what it's trying to run (I think there's some issue with the quotes or something, so if I could see the actual string in the command line, I'd be able to see exactly what the problem is). My code looks like this:
var processStartInfo = new ProcessStartInfo("cmd", "/c"+commandString);
processStartInfo.CreateNoWindow = true;
Process.Start(processStartInfo);
So basically, I just want to see the string commandString written in the console. Any help would be greatly greatly appreciated.
string CommandLineString = #"""C:\Program Files\Microsoft SQL Server\100\Tools\Binn\bcp.exe"" ""SELECT * FROM table where date >= '2009-01-01'"" queryout ""C:\Data\data.dat"" -S DBSW0323 -d CMS -n -T";
In this case, the problem is probably just your lack of a space after "/c".
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
As for viewing in a command window, instead, you will probably be better off inspecting the Arguments property of your processStartInfo instance.
EDIT
Taking into account the command line details you posted, I believe this is what your issue is. Check out the following from cmd help:
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
If all of the following conditions are met, then quote characters
on the command line are preserved:
no /S switch
exactly two quote characters
no special characters between the two quote characters,
where special is one of: &<>()#^|
there are one or more whitespace characters between the
the two quote characters
the string between the two quote characters is the name
of an executable file.
Since you are using /c, you have quote and special char issues still. Try wrapping your entire commandString in a set of quotes.
Take this simple example for instance (creating temp.txt manually of course):
string commandString = #"""C:\WINDOWS\Notepad.exe"" ""C:\temp.txt""";
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
The command line to be executed will be: /c "C:\WINDOWS\Notepad.exe" "C:\temp.txt", but this will fail since "C:\temp.txt" is not an executable.
If you wrap the whole thing in one last set of quotes, you should see the intended result:
string commandString = #"""""C:\WINDOWS\Notepad.exe"" ""C:\temp.txt""""";
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
Resulting in a command line of: /c ""C:\WINDOWS\Notepad.exe" "C:\temp.txt"" and ultimately opening notepad with your test file.
That string is not "written" to the console, it's part of the argument list for a program you launch (which in this case happens to be cmd.exe). Since the console created is owned by that program, unless it wants to print its arguments for its own reasons (which it won't) this is not directly doable.
If you simply want to debug then why not inspect the value of commandString, or write it out into a log file?
If you absolutely need the command line to be displayed in the console then you could resort to hacks (run another intermediate program that prints the command line and then calls cmd.exe with it), but unless there is some other good reason to use this approach I would not recommend it.
This one seems trivial but the answer has eluded me for a few days now.
I have a Windows batch file, that calls a C# program to do an extra verification that cannot be done in a batch file. After the verification is complete I need to return a status and a string back to the calling shell.
Now the return value is trivial and my C# console app simply sets a return value (exit code if you will). And I thought the string will also be a piece of cake. I attempted to define a new shell variable using the:
Environment.SetEnvironmentVariable("ERR", "Some text");
This call should (and does) define a shell variable within the current process - that is the very C# process that created the variable. The value is lost as soon as the C# app terminates and the shell that created the C# app knows nothing about the variable. So... A call with no particular use... At all... Unless perhaps if I created a child process from the C3 app, perhaps it would inherit my variables.
The EnvironmentVariableTarget.Machine and EnvironmentVariableTarget.User targets for the SetEnvironmentVariable call don't solve the problem either, as only a newly created process will get these new values from the registry.
So the only working solution I can think of is:
write to stdout
write to a file
encode extra meaning into the return value
The first two are a bit ugly and the last one has its limitations and problems.
Any other ideas (how to set a shell variable in the parent process)? Maybe such shell variable modifications are a security concern (think PATH)...
Thank-you for your time.
I had the same problem as Ryan and the only thing that came to my mind as a work-around was to write a batch in error out to set the variable and to call it from the batch.
ConsoleApplication1.exe:
'put some sensible code here
'put result in variable myResult
Dim myResult As String = Guid.NewGuid().ToString("D").ToUpperInvariant()
Console.WriteLine("Normal output from the consonle app")
Console.Error.WriteLine("#ECHO OFF")
Console.Error.WriteLine("SET zzzResult={0}", myResult)
Test.cmd (the calling batch):
#ECHO OFF
:Jump to folder of batch file
PUSHD %~d0%~p0
:Define a temp file
SET zzzTempFile=%TEMP%\TMP%Random%.CMD
:Call .NET console app
ConsoleApplication1.exe 2>%zzzTempFile%
:Call the generated batch file
CALL %zzzTempFile%
:Clean up temp file
DEL %zzzTempFile%
:Clean up variable
SET zzzTempFile=
:Do something with the result
ECHO Yeah, we finally got it!
ECHO:
ECHO The value is "%zzzResult%".
ECHO:
:Clean up result variable
SET zzzResult=
:Go back to original folder
POPD
That should do the trick. And yes, I do know this is an old post and Ryan is solving other issues by now, but there might be still somebody else out there having the same problem...
What you are asking is to be able to arbitrarily write to the memory space of a running process. For good reason, this is not possible without SeDebugPrivilege.
Any of the three solutions you list will work. Stdout is the standard way to communicate with a batch script.
By the way, you're writing a Windows batch file. I'm pretty sure the ship has already sailed on "a bit ugly".
If you want to put a value of some output into a variable in the batch you can use the following construct:
FOR /F "usebackq tokens=4 delims=\[\] " %i IN (`ver`) DO set VERSION=%i
ECHO %VERSION%
Output on my OS:
6.1.7601
'usebackq' means we are using back quotes which gives the ability to use a fileset in the command quoted with double quotes. You may not need this. 'tokens' means the index in the resulting string array to select (it can be a range M-N). If you need to skip lines use 'skip=X'). 'delims' are the string separators to use (like string-Split() in .Net).
You will put your console app instead of 'ver' and adapt the delimiters and tokens to match your specific output. If you have more variables to fill you will need to make the if a bit more complex but that should make a good start.
My BAT is a bit rusty, but I think it's possible to retrieve the 'exit' code from processes you've run externally, perhaps via %ERRORLEVEL%. If that's the case, make sure to exit your program via
Environment.Exit(123); // where 123 = error code
You can't add any messages, so you'll have to do that in the .bat file.
If this isn't the case, stdout is probably the best way.
After stumbling on this myself as well recently, I came up with this approach. What I did is run the bat file using the Process class, i.e.
// Spawn your process as you normally would... but also have it dump the environment varaibles
Process process = new Process();
process.StartInfo.FileName = mybatfile.bat;
process.StartInfo.Arguments = #"&&set>>envirodump.txt";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = false;
process.Start();
string output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
// Read the environment variable lines into a string array
string[] envirolines = File.ReadAllLines("envirodump.txt");
File.Delete("envirodump.txt");
// Now simply set the environment variables in the parent process
foreach(string line in a)
{
string var = line.Split('=')[0];
string val = line.Split('=')[1];
Environment.SetEnvironmentVariable(var, val);
}
This seems to have worked for me. It's not the cleanest approach, but will work in a bind. :)