We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Running gradle tests uses ./gradlew if the file exists, or gradle otherwise.
./gradlew
gradle
On windows with the default &shell=cmd.exe this leads to a cryptic
&shell=cmd.exe
'.' is not recognized as an internal or external command, operable program or batch file.
This is because cmd.exe uses the current directory by default and gets confused by the ./. The relevant lines are
./
https://github.com/vim-test/vim-test/blob/master/autoload/test/java/gradletest.vim#L114 https://github.com/vim-test/vim-test/blob/master/autoload/test/kotlin/gradletest.vim#L67
An explicit check fixes the error but is a tad ugly:
function! test#java#gradletest#executable() abort if findfile('gradlew') ==# 'gradlew' if &shell =~? "cmd.exe$" return 'gradlew test' else return './gradlew test' endif else return 'gradle test' endif endfunction
Is there some existing pattern to handle this problem in other test types?
The text was updated successfully, but these errors were encountered:
Thank you for spotting this, does the issue just occur with Kotlin or other test runners?
Sorry, something went wrong.
No branches or pull requests
Running gradle tests uses
./gradlew
if the file exists, orgradle
otherwise.On windows with the default
&shell=cmd.exe
this leads to a crypticThis is because cmd.exe uses the current directory by default and gets confused by the
./
.The relevant lines are
https://github.com/vim-test/vim-test/blob/master/autoload/test/java/gradletest.vim#L114
https://github.com/vim-test/vim-test/blob/master/autoload/test/kotlin/gradletest.vim#L67
An explicit check fixes the error but is a tad ugly:
Is there some existing pattern to handle this problem in other test types?
The text was updated successfully, but these errors were encountered: