<div dir="ltr">Hi!<div><br></div><div>I have been investigating ticket 13157 regarding quotes in arguments, since the error is interfering with an application I am developing.</div><div><br></div><div>I have identified the problem and solved it in source, but before I work on submitting any patches I want to make sure that I am not misunderstanding something and that the changes do not break anything.</div><div><br></div><div>Note that I have not tested using Unix, guest or host, so I cannot comment on the handling of command-line arguments for that platform.</div><div><br></div><div>Quick recap of the problem: When starting a new guest process, any command-line arguments that contain double quotes are incorrectly sent to the process as they are replaced with backslashes.</div><div><br></div><div>An example would be the argument </div><div>TRANSFORMS="C:\path to file" </div><div>being replaced with </div><div>TRANSFORMS=\C:\path to file\</div><div><br></div><div>As far as I can tell, this error is a combination of two problems.</div><div><br></div><div>Both in VBox\Runtime\common\misc\getoptargv.cpp </div><div><br></div><div>* RTGetOptArgvFromString</div><div>The function splits a string into an array of arguments but does not correctly handle double quotes within a string.</div><div><br></div><div>Give it the following input:</div><div>argument1 "argument2=\"test\""</div><div><br></div><div>And you will get:</div><div>[0] argument1</div><div>[1] argument2=\test\</div><div><br></div><div>The problem seems to be that the function strips double quotes from the input string and does not take into account that they might be a part of an argument, rather than enclosing an argument.</div><div>I have modified this behavior to only consider non-escaped double quotes as enclosing arguments and include backslash-escaped double quotes in the output string. </div><div><br></div><div>This gives the result:</div><div><div>[0] argument1</div><div>[1] argument2="test"</div></div><div><br></div><div><br></div><div>This is the first part of the problem, however it isn't the whole story because there are also problems with the function that creates the argument string used for starting a new process.</div><div><br></div><div>The RTGetOptArgvToString function performs this action, and what it does is always enclose arguments that contain characters that should be escaped in double quotes.</div><div>Take the following argument array as an example:</div><div><br></div><div>[0] argument="C:\path to file\filename.dat"</div><div><br></div><div>Because of the space in the argument, RTGetOptArgvToString will output the following argument string:</div><div>"argument="C:\path to file\filename.dat""</div><div><br></div><div>Some applications, notably MSIEXEC, does not handle this double quotation and I do not see it being necessary.</div><div>I modified the rtGetOpArgvRequiresQuoting function which RTGetOptArgvToString uses to determine if an argument should be escaped to, so that it only returns true if the argument contains characters that should be escaped that are not enclosed in double quotes.</div><div><br></div><div>This made me a little unsure of the necessity of the escaping in RTGetOptArgvToString though - it seems as though everything is escaped as required by the command-line interpreter (>< etc.) and to my knowledge this is not necessary when creating processes directly as the Guest Additions do.<br></div><div><br></div><div>I realize this is a lot of input on an error that affects very few users, but I would appreciate any feedback that could assist me in creating a suitable patch for this issue.</div><div><br></div><div>Kind regards,</div><div>Magnus</div></div>