search

fclp / fluent-command-line-parser

A simple, strongly typed .NET C# command line parser library using a fluent easy to use interface
Other
530 stars 86 forks source link

Switch values ending in \" not parsing correctly #63

Open brecko opened 8 years ago

brecko commented 8 years ago

When a switch such as --outputpath "C:\" is used or "\some_unc_path" or "\some_unc_path\" or "c:\some_path\" is used, the \ is getting used as an escape character.

NTTAKR commented 8 years ago

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

brecko commented 8 years ago

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 commented 8 years ago

@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? :smile:

NTTAKR commented 8 years ago

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 commented 8 years ago

Thank you to both in advance!! :)

EricZimmerman commented 5 years ago

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