not a valid path: /c/Users/chris/.sdkman\var\candidates

[xpusostomos]

I was using sdkman for many years with cygwin, it was great. Some months back, sdkman broke it, for no good reason I could see. But I was excited recently to try it again, and it 95% works! yay! Because I was lost without it.

However, this command gives an error:

$ sdk default groovy 4.0.19
thread 'main' panicked at src\lib.rs:38:13:
not a valid path: /c/Users/chris/.sdkman\var\candidates
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

[marc0der]

Hi @xpusostomos, our problem is that Cygwin doesn't handle paths properly, and Rust does not support that. We now build proper Windows binaries that behave in the way that a Windows binary should, but Cygwin expects windows binaries to behave as Unix. This problem will only get worse as we port more across to Rust. I know that GitBash does the right thing and works well with SDKMAN on Windows. Alternatively, you could also try WSL2.

[xpusostomos]

@marc0der having a unix shell call a windows program, is hardly natural, and I was going to respond to you along the lines of, would it kill you to use $(cygpath -w ${SOMETHING}) anytime on windows you want a windows path sent into a rust program... (alias cygpath to "echo" on other architectures)...

however....

when I try sdk on windows right now (doing an upgrade on sdk to be sure), it all works again, including "sdk default groovy blah"... so I presume someone has fixed it...

At the end of the day, bash, whether the cygwin version or not, works with the paths you give it. Cygwin works perfectly happy with C:/ as the beginning of a path, just the same as windows does. So as long as you don't contaminate your variables with a cygwinism, then you don't even need cygpath.. not that cygpath is that hard.

[marc0der]

would it kill you to use (cygpath−w{SOMETHING}) anytime on windows you want a windows path sent into a rust program

We won't be sending anything to a Rust program from bash. Rust reads and builds its paths natively.

when I try sdk on windows right now (doing an upgrade on sdk to be sure), it all works again, including "sdk default groovy blah"... so I presume someone has fixed it...

I assume that your libexec folder is empty, which means that SDKMAN is falling back on the deprecated bash functions. That said, we will be removing those functions at some point as they grow out of date.

[xpusostomos]

@marc0der libexec has 5 .exe programs in there. The above error I reported looks to me like a crash inside a rust program to me. If you never pass a path into rust from bash, I don't understand the complaints about cygwin paths being an issue... and at this point in history, they don't appear to be an issue. However the above error seems to indicate a cygwin path got into rust.

cygwin is a project that probably has tens of thousands of man years of development put into it. It should not be onerous to make the... apparently minimal... effort to keep it working.