Seem to have to use "--" to pass an argument? (Forward "/" syntax not supported)

[jsmarsch]

I'm using version 1.9.71 (latest from nuget as of today). I'm a fairly new user, so maybe I'm doing something wrong, but I found that it only parses successfully if each arguement is passed with a double dash, like:

myApp --arg1 value --arg2 value etc.

I can do that, but it seems kind of unusual. Most users are used to either a single dash or a forward slash to specify args. Is there a way to change that behavior?

if it helps, here is a snippet of my option class:

class CommandLineOptions
{
[Option("longname", Required=true, HelpText="blah")]
public string TheProperty { get; set; }

[nemec]

AFAIK the double-dash is your only option. For a bit of context, Windows is the only OS that uses - or / for specifying arguments. Everywhere else---Linux, UNIX, BSD---a double-dash is used to indicate options with more than one character (sometimes a single dash is used, but that's often reserved just for single character options like -c).

See getopt short and long options for the syntax this library is based on.

[jsmarsch]

Thanks Dan -- do get what you are saying, but most of my users are windows
users, so I guess I need something that is going to follow that convention
-- when in Rome, you know.

Thanks all!

On Thursday, November 7, 2013, Dan Nemec wrote:

AFAIK the double-dash is your only option. For a bit of context, Windows
is the only OS that uses - or / for specifying arguments. Everywhere
else---Linux, UNIX, BSD---a double-dash is used to indicate options with
more than one character (sometimes a single dash is used, but that's often
reserved just for single character options like -c).

See getopthttp://www.gnu.org/software/libc/manual/html_node/Example-of-Getopt.html#Example-of-Getoptshort and long options for the syntax this library is based on.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/108#issuecomment-28021007
.

[coyot]

There is a setting you can disable two dashes. The documentation for input parameters is here: https://commandline.codeplex.com/wikipage?title=Attributes-Define-Your-Syntax

I suggest mainly you cope with /? or something like that - so people will be able to read documentation.

[Ehryk]

Can the support for /{single letter}, /{long word} and/or /? for help be added?

[nemec]

You could easily allow modifying the - to /, but you'd still only be able parse options like /c, //longopt, or //help. To parse the Windows way you'd need to rewrite the entire parser.

commandline depends on the semantics of getopt to understand that -i4 is a single-letter option with the value of 4 and not a long option. Throwing away the notion of "single dash is short opt, double dash is long opt" is an entirely different thing. If the library could be redesigned, allowing multiple parsing methods would be a good idea but I don't know if it's easy to do with the current codebase.

[Ehryk]

I'd be happy with that. Mostly I just want /? to be --help and /c short commands. Could it work both ways simultaneously?

example.exe /m -v --file File.txt

[nemec]

This and this might be where you can change the help command. Here is where the dashes are processed. The easiest thing to do would be to replace dashes with slashes, but you might be able to modify the tokenizer to accept slashes for short commands and dashes for long ones.

Of course, the whole idea is moot if you're not interested in compiling it yourself. I haven't seen the author around here in over a year.

[gsscoder]

In 2.0 is even simpler hack the code.
To change - \ -- to / for example, just modify:
https://github.com/gsscoder/commandline/blob/master/src/CommandLine/Core/Tokenizer.cs

Or better, hack Parser.cs and supply it your tokenize function.

If you want stop processing for special /? or -?, just add an handler here:
https://github.com/gsscoder/commandline/blob/master/src/CommandLine/Core/PreprocessorGuards.cs

OK? I close the issue for now. Thanks everyone for nice discussion! 👍

[Ehryk]

@gsscoder, my goal in this is not to 'hack the code' in a one-off sense, I'm asking if '/' can be added to the Tokenizer for the main trunk, by default. If you would accept the pull request I will create one and test it, but I'm essentially asking why '/a', '/b', '/?' can't be by default interpreted as '-a', '-b', '--help'?

This is coming from a windows-centric mindset, where arguments are frequently prefaced with /.

[nemec]

@Ehryk I don't think that this request will ever make it in as the "Windows" style wouldn't work with some features integral to the "getopt" style -- namely, short name merging (-ab instead of -a -b).

While it's possible from a technical perspective, this project strives to adhere to the getopt style of parameter passing and a Windows-centric style parser might be better off as a separate project. Windows-style parsing has its own methods of escaping and delimiting that I would expect to be included in a good library but are incompatible with getopt.

[Ehryk]

Why couldn't it support proper getopt, with forward slashes too? For example, /ab working the same as -ab? I suppose that it would conflict with /p as a path from the Linux root, is that why? It does seem a more natural fit for a .NET project.

[nemec]

That would work, but I assume you want to support long names with a single slash, too, rather than a double slash.

class Opts
{
    [Option('a', "ab")]
    public bool Abs { get; set; }

    [Option('b', "boots")]
    public bool Boots { get; set; }
}

This would have an ambiguous definition when using /ab.

[gsscoder]

@Ehryk, getopt() supports / slashes? It's new to me... Can I have the link?

[Ehryk]

@gsscoder no, getopt() does not support / slashes. I'm asking for an extension on getopt() for windows usage (more in line with this being a .NET project).

@nemec I'm completely happy with a hybrid approach: /ab = -ab and //long = --long (I.E. / just being an allowed variant of -).

The only issue I see here is non-Windows pathing: blah.exe /i /var/log/file.txt, so I think this would be best implemented as an option that could be disabled: allow -,-- only (default), /,// only, or either one /,-,//,--.

[nemec]

@Ehryk in that case I have a many fewer objections. The double slash looks weird to me but as long as the documentation is clear that it only affects the argument delimiter and otherwise parsing is the same, I don't see why it couldn't be added.

For /? we should make the Preprocessor Guards for Help and Version configurable (both long and short) so that you could add your own short name of ? -- of course stuff like myapp.exe /a?b will be legal, but you can probably live with that.

Under non-Windows, you (as in the app, not CommandLine) could add your own OS detection and choose the flag delimiter based on that. Unfortunately, you can't quote the path before executing because cmd/ps will do some lexing for you.

myapp.exe /i "/var/log/file" becomes the args array string[]{"/i", "/var/log/file"} with no way to tell it was quoted unless you use System.Environment.CommandLine and split it yourself.

[gsscoder]

agree with @nemec about // double slash, but I think that I've to surrender and support Windows style syntax due too various requests

now, @Ehryk, the point is to define a new standard or in library internals a new Tokenizer

@nemec, will be agree with me that a possible solution could be add boolean property in ParserSettings that will switch to a future WindowsTokenizer

on a thing I'm sure: I'm against to allow hybrid between *nix and Windows syntax!