-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find alias even when flag order is differently defined #18
Comments
@pradyunsg You might be interesting in watching this one. I'd also be glad for any suggestions and comments. |
Indeed I am interested. I haven't thought about this yet. I'll let you know what I think when I do. |
As much as I would like this, it is inherently difficult to provide proper support for this...
I don't see how this is a non-trivial matter... It should be pretty simple to filter out the flags (loop with conditional break), till the
IMO the latter is not the most-common pattern CLI design. So, it should be fine to ignore it... Plus, I don't expect the first iteration to have support for multi-character options. In any case, it is possible to simply ignore that specific alias if it causes issues. How about maintaining a list of commands that have this behaviour? No. Too much effort, too little reward.
This seems to be the blocker to me. It is very difficult to know if it's a flag or argument option... And assuming either would be in-correct... AFAICS, the only ambiguity exists with
Not for me. I do not want to be checking that what is being suggested to me by
👍
👍 Obviously. What do you think? |
Just a clarification (will respond to the rest later): When I write non-trivial I don't mean hard to do, but rather adding special cases to the code which will make it harder to read and more brittle. |
Basically all tools written in Go(lang) that use the standard flag parser have this behaviour. (I dislike it a lot). Overall you made very good points and I believe our intersection in concerns is large. We could start with minimal support, starting with obvious, easy, and always (i.e. no best guesses, no assumptions, etc.) correct cases and then add support as we feel like and think the trade-offs are worth it. |
Ah, Go. I lost enthusiasm for it ever since Rust came out... But that's another topic. I don't like that behaviour at all, especially because both option styles (
Thanks! 😄
Sounds good to me! 👍 So, what is that minimal "safe" subset? I would like to ignore any argument options (how many arguments? Till next option? only one? can't know), for now. Flag options should be detect able. In my head, this would be the processing:
|
So I tried to come up with some test cases that define a minimal support set for this feature and declared and skipped other tests that are quite common real-life cases but are either hard or impossible to match. Please have a look at #23 which only contains the test cases the feature should be spec'd against. While doing so I encountered something we haven't discussed yet: Even if we are not sure if a flag is argument flag (with argument provided) or boolean flag, if the alias mapping defines the flag and argument we should obviously match this. E.g.: So it might be that we have to consider "flag-reordering" not as replacement but as sequential and additional step after prefix matching: Either prefix matching did find a match, then consider flag-reordering the rest and try again to find something even better, or prefix matching did not find a match, then again consider flag-reordering but this time everything and try again to find something. |
Currently the following does not work:
should be suggestion:
l foo
.The algorithm should change to a heuristic that in most cases finds the alias. What makes this non-trivial is at least:
--
must be respected as flag and argument terminator-foo
is indistinguishable from-f -o -o
for some commands but is actually--foo
for other commands-f bar
,--foo bar
, and--foo=bar
are not always identical depending on if-f|--foo
is and argument flag or bool flag.Acceptance criteria and constraints:
alias l=ls '-l -h -a'
are handled and not yetalias l=ls -lha'
.docker run foo -- -it
!=dr foo
(ordr foo --
) if aliasalias dr='docker run -it'
defined.The text was updated successfully, but these errors were encountered: