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!
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).
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