[Mono-list] Starting processes with parameters from Mono
Gonzalo Paniagua Javier
Tue, 06 Apr 2004 16:02:17 +0200
El mié, 07-04-2004 a las 00:15, Jonathan Gilbert escribió:
> At 10:12 AM 05/04/2004 +0200, Gonzalo wrote:
> >MS seems to run 'cmd /c yourprogram yourparameters'. The diference is
> >that cmd on windows also handles something like 'cmd /c file.pdf' by
> >opening acrobat reader and stuff like that.
> Actually I'm pretty sure the MS implementation use the Win32 API function
> "ShellExecute". Windows treats files in a very slightly object-oriented
> manner; file "classes" are defined in the registry (this is what
> HKEY_CLASSES_ROOT is all about), and associations are made between
> extensions and classes (if you look up '.txt' under HKCR, you'll see that
> it maps to the class 'txtfile'). Each class has a set of "verbs", each one
> of which defines a certain action that can be performed with the file. Each
> verb has a name and a command-line which is expanded using the environment,
> as well as %1 => the full path and filename of the file being executed. If
> you look up HKCR\txtfile\shell\open, you should find that its value is
> something along the lines of 'notepad.exe "%1"'. The default verb can be
> specified, but if it's not, the default of the default is the "open" verb.
> Once the class and default verb have been obtained from the registry,
> ShellExecute then spawns the specified application with the parameters that
> result from expanding the command-line string from the registry.
Nice to know this, but, anyway, running 'cmd /c whatever arguments'
achieves what we need.
> Obviously, this concept is very alien to vanilla unix, but some of the X
> environments have added similar systems. I'm not sure exactly how
> binfmt-misc works, but it seems to also operate along a similar line: a
> file can be shunted to an "interpreter" (Acrobat Reader being an example of
> an interpreter for a .PDF file), based on some criteria. I haven't done
> much research on this, so I don't know the details :-)
There's kfmclient and there used to be a gnome-open that handle this. I
filed a bug report for it some time ago but have not yet decided what to
do (suggestion welcome on bugzilla).
> If anyone is interested in approximating ShellExecute for unix systems, it
> is important to note the method in which ShellExecute searches for the binary:
> - If the first "word" on the command-line is enclosed in double-quotes, it
> is the only thing that is checked:
> ShellExecute("\"c:\\Program Files\\Fubar Corp\\Example 1.exe\" params"); //
> for demonstration purposes only; some parameters are missing
> This can only execute the file "c:\Program Files\Fubar Corp\Example 1.exe".
> - If the first word is not enclosed in double-quotes, then things get
> interesting :-) ShellExecute searches for a binary file by treating the
> first 'n' words, where 'n' is looped up starting from 1.
> ShellExecute("c:\\Program Files\\Fubar Corp\\Example 1.exe params"); //
> For this command-line, ShellExecute searches for files whose name (w/o
> extension) are each of the following, in this order:
> "c:\\Program" (.exe, .com, .bat, .cmd, ..)
> "c:\\Program Files\\Fubar" (.exe, .com, .bat, .cmd, ..)
> "c:\\Program Files\\Fubar Corp\\Example" (.exe, .com, .bat, .cmd, ..)
> "c:\\Program Files\\Fubar Corp\\Example 1.exe" (.exe, .com, .bat, .cmd, ..)
> "c:\\Program Files\\Fubar Corp\\Example 1.exe params" (.exe, .com, .bat,
> .cmd, ..)
> Any one of those first 3 can be used to "hijack" the program, such that
> badly-written code using ShellExecute will run the wrong binary! I believe
> the MSDN documentation for ShellExecute warns about this issue.
Isn't that what you get with 'cmd /c whatever'? Also note that
ProcessStartInfo has a FileName property. If this is a full path, that's
the only thing searched for (plus exe, com, bat and cmd extensions if
under windows). On *nix we use $SHELL to get the shell under which we
run the command when UseShellExecute is true.