take single letter CLI options with one leading hyphen, such as `-lwc`
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
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.
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 :-)
@Leont yes, but is there anything that prevents us from swapping the current argument parser with code from Getopt::Long?
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.
IRC discussion: https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-04-26#l215
@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
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.
Before this issue can be closed, we will need spectests! :-)