Closed empjustine closed 4 years ago
It's moving files out of your home directory because it failed to find mktemp
, where it would normally do all its work in a temp directory. I'm pretty sure asdf doesn't officially support Windows, and at this time the asdf-java plugin officially supports linux and MacOS. You are welcome to attempt to add support for Windows if you'd like.
I'm not using set -e
because the check-jq
the check failing would cause the script to exit before the usage could be printed.
In the mean time, I can add a default case for unsupported operating systems that will exit early as opposed to damaging one's home directory.
mktemp actually works, and it's set (in this example run) to /tmp/asdf-java.3wteNNs4
I think at least enabling set -e
before the untar/move part (near the offending dir=$(set -- $(ls -d */) ; echo ${1})
line) would help a lot already.
I don't think attempting to progress if any of the following steps failed is safe in any environment after that point.
I'll consider it. In the mean time, could you tell me what the result of running uname -s
is on your system? I suspect your Windows system is not identifying itself as Windows. The untar is failing, because as your logs have indicated, it's not downloading a tar file - it's downloading a zip file.
How does it know to look for the Windows build? The only options for it to set the OS variable to are "mac" and "linux". So if it sets it to one of those, then it would never be able to query for the Windows build. Could you tell me more about your environment? Did you modify the script?
I had to modify the uname -s
case with
# MSYS2 MinGW 64-bit or 64-bit Git for Windows => MINGW64_NT-10.0-18362
# MSYS2 MSYS => MSYS_NT-10.0-18362
MINGW64_NT*|MSYS_NT*) OS="windows"
SHA256SUM="sha256sum"
STAT="stat -c %Z ${CACHE_DIR}/*"
TEMP_DIR="$(mktemp -dp /tmp 'asdf-java.XXXXXXXX')"
set -x
;;
To get that part working. Also the reason why I had the set -x logs activated, to test what was gonna break next.
To get the symlinks working I first tried a shim exec shell script but that was a mess so I'm for now just using cp. Not sure how to solve this problem in a elegant and cross-platform way.
@empjustine Please feel free to re-open this issue if you have any updates/PRs/etc. For now I'll be closing this issue (so that I can more readily see when new issues crop up). Thanks in advance for your understanding and efforts!
Well, for me, not only is that issue happening too, but some downloads fail with a message like so:
❯ asdf install java adopt-openjdk-9.0.4+1
curl: no URL specified!
curl: try 'curl --help' or 'curl --manual' for more information
It's not consistent, since Java 10 and above fails with an error like described in this issue, complete with all not-dotfile elements on my home folder disappearing.
It also seems to happen only with AdoptOpenJDK versions: Amazon Corretto seems to install and work properly.
I looked into the uname fix by @empjustine, but when I run uname -s
WSL already returns Linux
...
As an aside, I don't agree with that idea of closing an issue for increasing visibility of other issues, specially after just one or two months, and specially when there's currently only one single open issue right now.
I'd prefer tagging for that, if classifying issues is a problem; it's pretty easy to filter issues by their tags.
@Kaylebor If you'd like to commit to resolve this issue, I'll gladly reopen it for you.
asdf does not officially support Windows, so it's difficult for me to consider this a real issue. While I won't object to a "fix", to leave this hanging around as if it's some issue for me to resolve does not seem fair.
There is only one single open issue because of the very fact that even though I have a full time job and am the maintainer of more than one open source project, when an issue is open I drop almost everything I'm doing and work on the issue until it is resolved. If I were to become accustomed to having issues open (especially one's that I can not resolve and don't expect to resolve) then I would be less likely to notice new issues, and issues would not be resolved as quickly as they are.
@Kaylebor I use an API at https://adoptopenjdk.net/. Not every build of the JDK on adoptopenjdk.net is available for every platform.
Expected Behavior:
asdf install java 'adopt-openjdk-11.0.5+10_openj9-0.17.0'
New Java installed.
Current Behavior
asdf install java 'adopt-openjdk-11.0.5+10_openj9-0.17.0'
will move all non-hidden, non-locked files in${HOME}
if the tarfile fails to expand.Possible Solutions
Escape all shell variable expansions.
Use the special parameter
--
to avoid confusing filenames with command parameters.Make script use 'set -e', to abort instead of moving/destroying data.
Detailed logs
(captured with set -x in script)
Context (Environment)
https://github.com/halcyon/asdf-java/blob/master/bin/functions#L113
dir
is set to "", because$(set -- $(ls -d */) ; echo ${1})
failedhttps://github.com/halcyon/asdf-java/blob/master/bin/functions#L114
cd ${dir}
is the same ascd
https://github.com/halcyon/asdf-java/blob/master/bin/functions#L122
mv * ${ASDF_INSTALL_PATH}
means merge everything in last path to single file.