Switch values ending in \" not parsing correctly about fluent-command-line-parser

[NTTAKR]

Hi Brecko,

just stumbled upon that error myself and investigated a little.
This is not a problem of fluent-command-line-parser, but a general error due to commandline parsing.

If you just output the arguments to a commandline app like this:

app.exe --xx="C:" --yy="Test"

Then you will see as parameters:
0 = app.exe
1 = --xx=C:"
2 = --yy=Test

So the input parameters calling the parser are already wrong.

This is due to the fact that cmd.exe is converting " to "

You can prevent it, if you use "/" as directory separator character, or if you omit the trailing "" in a path (which of course will not work on the root of a drive).

Best regards,
Andreas Kroll

[EricZimmerman]

it is really not fun to have to have end users remember to not put a \ on a path with spaces, which breaks things.

id rather see the parse(string) overload or even better, have the project not deal with string[] args at all and hit the Environment object. the cmdLineTokenizer may work, but its GPL

[brecko]

Hi Andreas, Thanks for the information. I have thought about the '/' and dropping off the '', however, asking my users to remember to do so is problematic. It is one of those issues of command line parsing from the system itself which occurs prior to the lib getting to do anything, and how the library attempts to piece pieces back together if needed. By the time it gets to me the user of the lib, the command line has been processed by two separate libs. I am just asking here if there is some way for the fluent to attempt to piece things together. I am sure I am not the only one on windows to have ever come across this and it is common enough where a lib would be the best locations to resolve it for all...
If this bug/request gets punted, I would understand, the complexity is such that it may be too much for what's it worth...

Thanks!

[siywilliams]

@brecko @NTTAKR

I think this is a valid bug.

I've been lucky enough to be in control of arguments passed into my apps so my workaround to this so far is to ensure I don't include trailing ''.

If FCLP were to take on its own parsing a new FluentCommandLineParser.Parse(string) overload should be added which would do the conversion to string[].

In #44 @nelyom has provided some code at https://github.com/nelyom/cmdLineTokenizer which looks to do just that. There looks to be quite a few tests around it too. In the short term you could use something like the cmdLineTokenizer to produce the string[] and pass into FCLP - you're already using 2 separate libs surely another can't hurt? 😄

[NTTAKR]

Hi @siywilliams!

I totally agree with you.
I can't seem to remember since when cmd.exe or .NET Runtime is interpreting and converting " into " and which other transformation are also done.

The best solution - as you already stated - would be to NOT work with the parsed commandline, but instead use the Commandline String.
That way you totally have control about what is happening, and you even could make conversions possible as option, if needed.

If I have time, I might get around to making a pull request.

Best regards,
Andreas Kroll

[brecko]

Thank you to both in advance!! :)