Command Line arguments make me say arrg

IssueI have found a scenario where the command line arguments recieved by an application will fail and three arguments will be concatenated into two...

Say one has written a console application and duitfully checks the arguments passed in. One of the arguments targets a path instance. Now the user who is tech savy knows that he/she must enclose in quotes any path that has a space in it or it will be perceived as two seperate arguments. So c:\Program Files needs to be "C:\Program Files" and passed in accordingly.

But what happens when a user, say leaves a \ on the end of his/her path? Such as "C:\Temp\Dir1\"?

I will tell you, instead of interpreting it as a literal, thecommand line parser interprets it as an escape. Example say the program requires three arguments. If the user enters

-ab "C:\def\" GHI

The argument parser will return two arguments that look like this

  1. -ab
  2. C:\def" GHI
Expecting three werent you? So was I. Thoughts anyone.

Steps to Recreate
  1. Create a console application and copy example code below.
  2. Run the program on the command line with these arguments -ab "C:\def\" ghi
  3. See the program report:
    1. -ab
    2. C:\def" ghi
Platform
  • .Net 2
  • C#
  • VS2005
Example


staticvoid Main(string[] args )
{
foreach (string argin args)
Console.WriteLine(arg);
}



advTHANKSance
[2361 byte] By [OmegaMan] at [2007-12-24]
# 1
Interesting issue and one I can confirm... you may want to hop on over to Microsoft Connect and report it in the Visual Studio/.NET Framework section.
BrendanGrant at 2007-10-8 > top of Msdn Tech,Visual C#,Visual C# General...
# 2
Bizzare, this bug has been reported and Microsoft says its working by design! They state that when the user would need to escape a quote in a command line that this is done! Ya my users do that all the time....<g>

I have written a new issue saying that if you are going to treat a backslash as an escape, then it needs to be done in a consistent way. For example

"C:\\Program Files\\"

parsed should return

"C:\Program Files\"

yet it returns

"C:\\Program Files\"

hence it is not consistent.

I don't necessarily like escaping comand line arguments...I mentioned that this leads to confusion when dealing with paths. For a user on a command line would not expect to escape the argument when dealing with path variables. It leads to too much confusion.

Regardless it needs to be consistent and it is plainly not. Maybe I have elevated this on the radar...please go and vote on this issue. Thanks!

OmegaMan at 2007-10-8 > top of Msdn Tech,Visual C#,Visual C# General...
# 3

While I partially buy their explanation (provided you are using C++/C#/J# (I’m guessing on J#)... I’m puzzled as to how a VB.NET programmer would deal with this issue as they do not have the same kind of escape character sequences and seeing a \\ would likely to cause them to think it is even more broken than a C# programmer would.

While I understand what they are trying to do, I’m sad to say that I cannot immediately think of a better way that would enable what they want to do and not poke a single language’s developers short of compile time redirection to language specific versions of the desired methods (which would be even worse than it is today).

BrendanGrant at 2007-10-8 > top of Msdn Tech,Visual C#,Visual C# General...
# 4

The static System.Environment.CommandLine will provide the original untampered cmdline - should be straight forward to use this.

there is also System.Environment.GetCommandLineArgs() method but this is used to create the args parameter passed to main and suffers the same problem , I mention it because, when you use it the element 0 of the array contains the path to the excutable which you can use to strip the exe name from the System.Environment.CommandLine


Adrian

AdrianJMartin at 2007-10-8 > top of Msdn Tech,Visual C#,Visual C# General...
# 5
Use of theSystem.Environment.CommandLine is what Microsoft is saying as well and has closed the issue. Thanks everyone!

Microsoft's Response

Thank you for your feedback. The command line behavior you've mentioned is common to all DOS/command-line applications. For example, this ANSI C program has the same behavior:

// main.c
#include <stdio.h>

void main(int argc, char* argv[])
{
int i;
for(i = 0; i < argc; i++) {
printf("%s\n", argv[ i ]);
}
}

// program behavior:
C:\Program Files\Microsoft Visual Studio 8\VC>main.exe -ab "C:\\Program Files\\" ghi
main.exe
-ab
C:\\Program Files\
ghi


To avoid this behavior, you may access the raw command line value through the System.Environment.CommandLine property.

Thanks,
Josh Free
Base Class Library Development

OmegaMan at 2007-10-8 > top of Msdn Tech,Visual C#,Visual C# General...