./gradlew autocompletion fails with `command not found: gradlew`

[gayanper]

When trying to autocomplete when using the wrapper in the project ./gradlew it gives the following error

./gradlew _gradle:95: command not found: gradlew

This is on
OS: MacOS 13
Arch: aarch64
Shell: zsh

[acsdev]

I am running Arch Linux with zsh and I have exactly the same problem.

When I switch to bash it works perfectly.

[jdrider]

I was able to fix this on Mac by adding . to my PATH as noted in the Troubleshooting section.

zsh completion using ./gradlew may not work on Linux if you don't have . on your $PATH, so I recommend adding it in your ~/.zshrc file:

[kworth]

I was able to fix this on Mac by adding . to my PATH as noted in the Troubleshooting section.

zsh completion using ./gradlew may not work on Linux if you don't have . on your $PATH, so I recommend adding it in your ~/.zshrc file:

@gayanper did this work for you?

[gayanper]

@kworth Yes the suggestion works like a charm

[wwadge]

Not a great idea, that opens you up to malicious code. Eg I could drop an executable called "ls" and your "." in the path would execute that one instead the one in /bin/ls

[eslam-allam]

To anyone still struggling with this issue, I think I've come up with a solution that works and partially addresses wwadge's concerns:

# Gradle gradlew completion support
gradlew() {
    PATH=$PATH:$(pwd) ./gradlew "$@"
}

This way the current directory is only in path in the scope of the gradlew call not globally (so if you happen to have an executable called "ls" it's not going to be used if you type "ls" in your terminal). However, if gradlew itself attempts to use executable "x" that happens to be in your current directory then it will probably cause problems. Also (correct me if i'm wrong), if gradlew tries to add to PATH (which it should never do anyway) then it will end up including the current directory there too.

[antonmos]

+1 globally adding . to PATH is not a great solution https://superuser.com/questions/156582/why-is-not-in-the-path-by-default.

Given gradlew is the recommended approach, it would be great if there was an out of the box support for gradle task completion did not require extra setup.

[ThibautVerron]

Is adding . to the path really needed, or is it only about being able to resolve gradlew? Adding this to the bash/zshrc seems to work (at least for basic usage):

gradlew() {
    [ -x ./gradlew ] && ./gradlew "$@"
}

[reinsch82]

The issue is in the backlog of the relevant team and is prioritized by them.

---