I followed the install command, go get -u github.com/posener/complete/v2/gocomplete but got this error

package github.com/posener/complete/v2/gocomplete: cannot find package "github.com/posener/complete/v2/gocomplete" in any of

This PR adds support for auto-completion of file paths starting ~ and .. which translate to user home dir

Signed-off-by: anmolbabu [email protected]

goroutine 1 [running]:
.../vendor/github.com/posener/complete.(*Complete).Complete(0xc00038c690, 0x0)
	.../vendor/github.com/posener/complete/complete.go:67 +0x634
...
panic: runtime error: slice bounds out of range```

on tabbing for completion right after the name of the command. I haven't investigated closer but reverting to `1.1.2` fixes the issue.

This PR adds go module support for the complete package and also expands the gocomplete completion program for the go command to include completion for go help and go mod.

This PR also adds some missing flags for go clean.

Hey,

I noticed this bug when helping out with the other PRs. The autocomplete library can autocomplete a subcommand even if the given arguments wouldn't result in a valid command.

The issue stems from here: https://github.com/posener/complete/blob/master/command.go#L75-L76

For example nomad job has these subcommands:

$ nomad job
This command is accessed by using one of the subcommands below.

Subcommands:
    deployments    List deployments for a job
    dispatch       Dispatch an instance of a parameterized job
    history        Display all tracked versions of a job
    promote        Promote a job's canaries
    revert         Revert to a prior version of the job
    status         Display status information about a job

If I write: $ nomad job nonexistent stat<tab> it will autocomplete which is incorrect.

It is because the loop iterates till it finds a match, but really should give up if the argument leads to an incorrect subcommand.

As an alternative to inferring the completion command from the binary, allow the command to be specified.

This is necessary for using a subcommand as a the completion command.

This PR allows a command to specify that flags should only be completed when a prefix is present. The motivation behind this is to have the initial complation to prefer displaying argument completions and only display flag completions when the user enters "hyphen ".

Trying to build gocomplete gives an error:

go: finding github.com/posener/complete/gocomplete latest
go: github.com/posener/complete/[email protected]: parsing go.mod: unexpected module path "gocomplete"
go: error loading module requirements

The title isn't great. I'll explain. First, thanks for a great library. 🎉

I have a diff at the bottom of this issue with a fix, but I'm not sure how you want to unit test it so I didn't open a PR. Its a one-line fix.

The Problem

We have a CLI with the following two commands:

• nomad job status
• nomad status

They each implement their own arg autocompletion func. However, we noticed that only the outer one was ever being called. i.e. when you did nomad job status <tab>, it was returning the same output for nomad status <tab>. Further confusing: it seemed to call both autocomplete funcs, but only outputted the outer one.

We expected the behavior to only call the inner one.

A failing structure is shown below (where each Args PredictFucn outputs a different thing):

complete.Command{
    Sub: {
        "job": {
            Sub: {
                "status": {
                    Sub:         {},
                    Flags:       {},
                    GlobalFlags: {},
                    Args:        complete.PredictFunc {...},
                },
            },
            Flags:       {},
            GlobalFlags: {},
            Args:        nil,
        },
        "status": {
            Sub:         {},
            Flags:       {},
            GlobalFlags: {},
            Args:        complete.PredictFunc {...},
        },
    },
    Flags:       {},
    GlobalFlags: {},
    Args:        nil,
}

The Solution

I found the solution is to set only = true in c.predictwhen there is a subcommand found. This properly short-circuits the search. Otherwise, a parent matching command is found and overwrites any results. We also don't want the results merged, since the parent command does something totally different.

Here is the diff:

diff --git a/command.go b/command.go
index eeeb9e0..42b7f43 100644
--- a/command.go
+++ b/command.go
@@ -87,6 +87,7 @@ func (c *Command) predict(a Args) (options []string, only bool) {
        // if a sub command was entered, we won't add the parent command
        // completions and we return here.
        if subCommandFound {
+         only = true
                return
        }

We'd love to see this fixed!

Again, thanks for a great library. We're rolling this out to all HashiCorp tooling and its been great so far. This is the first bug we've ran into.

Hello, I am pretty exicted by the "Complete packages names" feature, which is exactly what I'm looking for. I assume it should work on any fully qualified package name that resides inside $GOPATH (which would default to ~/go if $GOPATH is not set).

Unfortunately, I couldn't make it work: go build github.c:repeat_one: go test github.com/gorilla/mu:repeat_one:

...no results. I have tried with and without GOPATH set, even after starting new bash. Any idea?

Some shells (inexplicably) occasionally have a COMP_POINT that is greater than the COMP_LINE size. When that happens completion should be based on length of the COMP_LINE to avoid an out of bounds error.

See the original hack fix here: https://github.com/chriswalz/bit/blob/master/cmd/bitcomplete.go on line 39

Now, the way of installation of Golang's pacage is as follow.

go install github.com/posener/complete/v2/gocomplete@latest

Can I modify a README of this repository?

This eliminates the need to use the unsupported bou.ke/monkey package, which fails to build on darwin/arm64. A better solution might be to remove the use of os.Exit entirely since it's only called with os.Exit(0) and exiting the program should be the responsibility of the caller to Complete.

I ran into troubles when implementing autocompletion for multiple positional arguments if flags are present.

Scenario:

• command with multiple positional arguments (required or optional, doesn't matter)
• command also accepts flags

In order to implement autocompletion for both position arguments, you need to check how many args have already been completed (via args.Completed). Here's an example from terraform (and the implementation).

And here's another example from my own CLI package.

These work fine when no flags are present, but it breaks down if there's flags because those flags will be included in args.Completed which means you can't naively just check the length of the array.

Example:

trellis deploy prod<tab>
# autocompletes to production

trellis deploy production exam<tab>
# autocompletes to example.com

trellis deploy --bran<tab>
# autocompletes to branch

trellis deploy --branch=foo prod<tab>
# does not autocomplete properly

Solution

I think I've been able to fix this by passing in the flag.FlagSet and parsing the args on every prediction. Then instead of checking the length of args.Completed, you use the length of parsed positional args. However, this adds a lot of complexity and seemed non-intuitive. Here's my solution so far: https://github.com/roots/trellis-cli/blob/dd2156bf2c923978ef3866c2b00517d903553cc8/trellis/complete.go#L38-L55

Since args and flags are handled separately in complete.Command, I'd kind of expect that the predict function just for args wouldn't include the flags. Or if it did (because that might be useful in case positional args depend on flags?), complete.Args would at least handle this automatically and provide both separately?

Idea

This would be a breaking change, but could this package move completed flags out of args.Completed and into args.FlagsCompleted? Or maybe Predict could be called like this for arguments:

c.Predict(args, flags)

Though that seems much more breaking. I'm probably missing other solutions as well though 😅

I would like to predict not hardcoded options but pull them from daemon every time. For example I input command app user remove, click TAB, and cli would offer me list of users which pulled by calling exec.Command("cli-get-users')

type ppred struct{}

func (y ppred) Predict(prefix string) []string {
	dateCmd := exec.Command("app", "user", "list")
	dateOut, err := dateCmd.Output()
	if err != nil {
		// handle error
	}
	s := strings.Split(strings.TrimSpace(string(dateOut)), "\n")
	return predict.Set(s).Predict(prefix)
}

Output is always empty, but when I run this code inside unit test, output is present and we're all good. If this is expected behaviour please someone explain or point me to explanation why it's not working.

Hello,

The Travis pipeline uses the CodeCov.io bash uploader on successful builds. The bash uploader was recently involved in a security incident. This is both a heads up as well as a request to consider removing the CodeCov dependency. If CodeCov is still needed would it be feasible to instead use a static known-good copy of the uploader instead of grabbing latest and executing it?

Thanks!

Is there any way for a subcommands' prediction to get its parents flags?

For example

adb -s FA81Y1A02186 uninstall com.blabla

-s flag correctly predicts FA81Y1A02186.

However, if i in the handler want to predict what packages to uninstall, i need the predicted flag value from before. Because i want to query the specific device for packages that are installed. Currently i can't. Maybe i've missed something.