take single letter CLI options with one leading hyphen, such as -lwc

[chee]

when wanting to implement some clones of common unix utilities i came across the fact that if you want to take single character options they need to be run as

> ./wc.p6 -l -w -c

but a common way of doing that in unix tools is

> wc -lwc

i think this would fit well as another option for %*SUB-MAIN-OPTS

[AlexDaniel]

As far as I remember, CLI option parsing has many problems and this is just one of them. Somebody knew more about this topic… @Leont ? Also, there may be some open PRs here https://github.com/rakudo/rakudo/pulls

I'm not sure if we should be fixing these things one by one or if we need a full overhaul. Doing it all at once will perhaps give us a way to version it nicely.

[Leont]

This doesn't fit at all into the existing argument parser. If you want that kind of interface I would recommend my Getopt::Long module :-)

[AlexDaniel]

@Leont yes, but is there anything that prevents us from swapping the current argument parser with code from Getopt::Long?

[Leont]

yes, but is there anything that prevents us from swapping the current argument parser with code from Getopt::Long?

While Getopt::Long is a drop-in replacement from a perl POV, it is not from an external point of view. It changes the command-line interface in several ways (including the one described in this ticket). It's not the kind of change one drops upon others without warning.

That said, making such a thing conditional on use v6.e makes perfect sense to me.

[AlexDaniel]

IRC discussion: https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-04-26#l215

[Leont]

@jnthn: So for -lwc you'd have to make a policy that -abc always becomes (:a, :b, :c), for example
jnthn: And so could never match a sub MAIN(:$abc) { }

That can be handled by adding a %*SUB-MAIN-OPTS option to parse -abc as :a, :b, :c, but --abc as :abc. That would bring Perl 6's argument parsing a lot closer to typical command line expectations.

jnthn: And as ugexe++ points out, if you try and do too much magic then you create ambiguous cases

I don't think all magic is required here.

jnthn: I'd quite like to retain the "first you transform, then you dispatch" approach, though. In that folks have a hope fo debugging it: at least they can get hold of the Capture and see which side is misbehaving :)

That sounds like something useful for programmers but not for end-users. In my experience,, it's actually quite hard to figure out what's going on that way for the latter. Take for example any of these:

zef --foo
zef foo
zef install
zef install Foo --timeout=1.2
zef install Foo --timeout=1 --timeout=2

All of these could have had error messages contains essential information for the end-user like "No command given", "install needs a module". Some of these don't really to be errors anyway but need zef to work around the gotchas (e.g. :$timeout should be a Real or Int(Real)). And ironically this one succeeds argument parsing even though one would expect it doesn't:

zef install Foo --timeout

[Leont]

That can be handled by adding a %*SUB-MAIN-OPTS option to parse -abc as :a, :b, :c, but --abc as :abc. That would bring Perl 6's argument parsing a lot closer to typical command line expectations.

I created rakudo/rakudo#2874 for this.

[lizmat]

Before this issue can be closed, we will need spectests! :-)