Backslash in argument value escapes quotation mark

[wpeti]

I hope I'm not using the library in the right way, but i just came across this issue:
I have an option class with a property called "Path", designed to be used as input container of folder or file paths. In case the user is trying to pass a value to this option by using the --Path= argument he/she experiences errors sometime. The cause of this is that they sometime pass on directory paths with a backslash in the end, like so: --Path="c:\test folder". In this unfortunate case the ending quotation mark is not recognized by the parser library and it parses the faulty "c:\test " argument value into my options object.
I'm not an expert of this library and I haven't checked every line of it's code (so far) but would say it's a bug which doesn't have any workaround implemented at the moment.

[gsscoder]

@wpeti, can you post exactly what you type from terminal, please?

[wpeti]

Hi gsscoder,
Thank you for the quick response! During the weekend i figured out that my problem lies within .Net's argument handling itself.

I called my tool like this:
myTool.exe --Accounts="Domain Users" --Path="C:\test folder" --Verbose --AddDomainAdmin

This got parsed into the main method's argument array, but instead of receiving every word in separate array items like i was expecting:
args[0]: --Accounts="Domain Users"
args[1]: --Path="C:\test folder"
args[2]: --AddDomainAdmin
args[3]: --Verbose

I actually only received two:
args[0]: --Accounts=Domain Users
args[1]: --Path=C:\test folder" --Verbose --AddDomainAdmin

And this was because of the backslash () before the quotation mark (").
I figured that i should pass two backslash (\) to get the right string parsed, so now the call looks like this:
myTool.exe --Accounts="Domain Users" --Path="C:\test folder\" --Verbose --AddDomainAdmin

Which is quite annoying, because the user can't just throw paths in with backslash endings, he/she have to be notified about this limitation.

Anyway, it's clearly not commandline's issue.

[nemec]

And this is why Linux uses forward slashes :) haha

This isn't the first time I've seen a degraded experience because of quirks in .Net's parsing. One option is to use Environment.CommandLine and parse the entire thing ourselves, but most users wouldn't know about it and it might be too "magical" to do it by default.

[gsscoder]

@wpeti, I can't say this for sure, but in a lot for Windows app I input path in *nix style without problems.

Can yo do the same and telle me what happens?

[GregWhiteDBA]

wow this took me ages to work out.. should have googled it first. guess its a double forward in the path or check for it in the code and add it in after its been parsed.