Console application, command line parameter issue

Hello:

I am building a console application and I am having an issue with the
command line arguments. A couple of my arguments are paths and they are
usually enclosed in double quotes. If one of the paths ends up in "\", it
causes the closing double quote to be ignored and the argument gets
concatenated with all the subsequent arguments until another double quote is
found or until the end of the string.

Example:

This command line parameter string:

arg1 "c:\arg2\" arg3

results in only two arguments stored in the args string[] parameter of
the Main method: 'arg1' and 'c:\arg\" arg3' instead of three arguments as
expected.

Is this an expected behavior? If so, is there any way around it?

Thanks in advance,
Ramon

RE: Console application, command line parameter issue

Hi Ramon,

Yes, this behavior is by design.

During the startup of the CLR, the CLR loader will call GetCommandLine
Win32 API to obtain the command-line in a single string. Then it will parse
the string into argument components. The parsing algorithm is similar to
the Environment.GetCommandLineArgs() method. Please refer to the remark
section of the link below:
http://msdn2.microsoft.com/en-us/library/system.environment. getcommandlinear
gs.aspx

"If 2n backslashes are followed by a quotation mark, the command-line
argument contains n backslashes, and quoted text begins if previous text
was unquoted or ends if previous text was quoted. If 2n+1 backslashes are
followed by a quotation mark, the command-line argument contains n
backslashes and a literal quotation mark. If n backslashes are not followed
by a quotation mark, the command-line argument contains n backslashes."

Since we are using one backslash with quotation mark and 0*2+1 = 1, the
algorithm will set the variable "n" to be zero. So zero backslashe will be
provide for the final arguments, which caused the second and third
arguments to be merged into single one.

To resolve this problem, we should use two backslashes in the second
arguments "c:\arg2\\" arg3.

Note: this is not not a code defeat but by design, since backslashe are
normally used to escape certain special character. Also, this algorithm is
the same as Win32 command line arguments parsing function
CommandLineToArgvW. See the Remarks section below:
http://msdn2.microsoft.com/en-us/library/bb776391.aspx

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx .
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

RE: Console application, command line parameter issue

Thank you for your quick and detailed response Jeffrey.

- Ramon


""Jeffrey Tan[MSFT]"" wrote:

> Hi Ramon,
>
> Yes, this behavior is by design.
>
> During the startup of the CLR, the CLR loader will call GetCommandLine
> Win32 API to obtain the command-line in a single string. Then it will parse
> the string into argument components. The parsing algorithm is similar to
> the Environment.GetCommandLineArgs() method. Please refer to the remark
> section of the link below:
> http://msdn2.microsoft.com/en-us/library/system.environment. getcommandlinear
> gs.aspx
>
> "If 2n backslashes are followed by a quotation mark, the command-line
> argument contains n backslashes, and quoted text begins if previous text
> was unquoted or ends if previous text was quoted. If 2n+1 backslashes are
> followed by a quotation mark, the command-line argument contains n
> backslashes and a literal quotation mark. If n backslashes are not followed
> by a quotation mark, the command-line argument contains n backslashes."
>
> Since we are using one backslash with quotation mark and 0*2+1 = 1, the
> algorithm will set the variable "n" to be zero. So zero backslashe will be
> provide for the final arguments, which caused the second and third
> arguments to be merged into single one.
>
> To resolve this problem, we should use two backslashes in the second
> arguments "c:\arg2\\" arg3.
>
> Note: this is not not a code defeat but by design, since backslashe are
> normally used to escape certain special character. Also, this algorithm is
> the same as Win32 command line arguments parsing function
> CommandLineToArgvW. See the Remarks section below:
> http://msdn2.microsoft.com/en-us/library/bb776391.aspx
>
> Hope it helps.
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Community Support
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>