Allow 7zip as alternative to Zip in SDKMAN with git-bash.

[aadrian]

Please allow the use of 7zip (with git-bash) too instead of just Zip.

7zip is compatible with Zip, and most users need to create a wrapper or link named "zip" to 7zip in order to make SDKMAN work with 7zip.

Simply allowing 7Zip too, would simplify the setup on Windows.

Thank you.

[marc0der]

PRs welcome.

[aadrian]

@marc0der if https://github.com/sdkman/sdkman-candidates-legacy is not used anymore: ("This is a retired service and is no longer in use!"),

where is https://github.com/sdkman/sdkman-candidates-legacy/blob/master/src/main/scripts/install.sh hosted (in what other repo?) ?

Since that install.sh seems to be what gets downloaded under https://get.sdkman.io/ (and would need a PR to support 7Zip).

[marc0der]

The repo you are looking for is the sdkman-hooks project. That said, it will only address a very small part as most of the work with zip actually happens in the sdkman-cli itself.

[qudongfang]

PRs welcome.

@marc0der Is this issue still open? I'd like to help with this.

[aapiro]

+1

[jeffque]

Hmmm, as a workaround, I add the following file to the PATH and, well, it works:

#!/bin/bash

gzip "$@"

Obviously it should be named zip. So, maybe aliasing internally to use gzip as the zip commando could work?

[marc0der]

@jeffque Even though that might get you across the line to install SDKMAN, it will break when installing any SDK version. I'd recommend not doing it that way.

[helpermethod]

I would prefer something like

if command -v gzip > /dev/null; then
    zip_cmd=gzip
else
    zip_cmd=zip
fi

Aliases seem like a good idea but often lead to hard to diagnose bugs.

[marc0der]

@helpermethod @jeffque I guess what I was trying to say is that gzip is not compatible with the command line arguments of Info-Zip zip. When I attempt to install for instance Java, I get the following error:

Downloading: java 17.0.2-tem

In progress...

Repackaging Java 17.0.2-tem...
zip: invalid option -- 'y'
Try `zip --help' for more information.

The CLI switches for gzip are as follows:

$ gzip -h
Usage: gzip [OPTION]... [FILE]...
Compress or uncompress FILEs (by default, compress FILES in-place).

Mandatory arguments to long options are mandatory for short options too.

  -c, --stdout      write on standard output, keep original files unchanged
  -d, --decompress  decompress
  -f, --force       force overwrite of output file and compress links
  -h, --help        give this help
  -k, --keep        keep (don't delete) input files
  -l, --list        list compressed file contents
  -L, --license     display software license
  -n, --no-name     do not save or restore the original name and timestamp
  -N, --name        save or restore the original name and timestamp
  -q, --quiet       suppress all warnings
  -r, --recursive   operate recursively on directories
      --rsyncable   make rsync-friendly archive
  -S, --suffix=SUF  use suffix SUF on compressed files
      --synchronous synchronous output (safer if system crashes, but slower)
  -t, --test        test compressed file integrity
  -v, --verbose     verbose mode
  -V, --version     display version number
  -1, --fast        compress faster
  -9, --best        compress better

With no FILE, or when FILE is -, read standard input.

Report bugs to <bug-gzip@gnu.org>.

But the switches for zip are:

$ zip -h
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
  The default action is to add or replace zipfile entries from list, which
  can include the special name - to compress standard input.
  If zipfile and list are omitted, zip compresses stdin to stdout.
  -f   freshen: only changed files  -u   update: only changed or new files
  -d   delete entries in zipfile    -m   move into zipfile (delete OS files)
  -r   recurse into directories     -j   junk (don't record) directory names
  -0   store only                   -l   convert LF to CR LF (-ll CR LF to LF)
  -1   compress faster              -9   compress better
  -q   quiet operation              -v   verbose operation/print version info
  -c   add one-line comments        -z   add zipfile comment
  -@   read names from stdin        -o   make zipfile as old as latest entry
  -x   exclude the following names  -i   include only the following names
  -F   fix zipfile (-FF try harder) -D   do not add directory entries
  -A   adjust self-extracting exe   -J   junk zipfile prefix (unzipsfx)
  -T   test zipfile integrity       -X   eXclude eXtra file attributes
  -y   store symbolic links as the link instead of the referenced file
  -e   encrypt                      -n   don't compress these suffixes
  -h2  show more help

I hope it makes more sense now.

That said, with the upcoming changes where we will no longer repack archives, this requirement on zip will go away, and we can probably use gzip for everything. Changes are coming very soon!

[alexanderankin]

I was reviewing this thread and was unable to find where in the sdkman-cli it uses the "zip" command is used. it appears to be from here:

https://api.sdkman.io/2/hooks/post/java/8.0.362-tem/linuxx64

```bash #!/bin/bash #Post Hook: linux-java-tarball function __sdkman_post_installation_hook { __sdkman_echo_debug "A Linux 64bit post-install hook was found for Java 8.0.362-tem." __sdkman_validate_binary_input "$binary_input" || return 1 local present_dir="$(pwd)" local work_dir="${SDKMAN_DIR}/tmp/out" echo "" echo "Repackaging Java 8.0.362-tem..." mkdir -p "$work_dir" /usr/bin/env tar zxf "$binary_input" -C "$work_dir" cd "$work_dir" /usr/bin/env zip -qyr "$zip_output" . cd "$present_dir" echo "" echo "Done repackaging..." __sdkman_echo_debug "Cleaning up residual files..." rm -f "$binary_input" rm -rf "$work_dir" } function __sdkman_validate_binary_input { if ! tar tzf "$1" &> /dev/null; then echo "Download has failed, aborting!" echo "" echo "Can not install java 8.0.362-tem at this time..." return 1 fi } ```

it appears as though it downloads a tar file, un tars it, zips it, then unzips it. Can you share the design goals of the system so that maybe someone can chip in with some contributions to address the issue raised here to the satisfaction of the project? thanks!

[marc0der]

Hi @alexanderankin, the internals of SDKMAN currently rely on all archives being zips. The choice of having the convention of zip files was taken early on because:

• there was no way of telling what resource curl is re-directing to, so we decided to standardise on zip files for simplicity.
• most SDKs are distributed as zips, with only a small percentage as tarballs

When we later introduced the JDK, some platform distributions were not in zip format. To bridge the gap, we wrote serverside hooks executed on the fly, transforming the tarballs into the zip format we understand. This is where the zip command comes into play.

Since that time, @hgeraldino has done excellent work on our broker service to help infer the binary type. We now have a header returned as part of the binary redirect, which tells us if it is a zip, tarball (or something else). Unfortunately, this work hasn't progressed much further, and we still rely on the tarball -> zip hack to help with JDK installation. Hopefully, we will see this work progress at some point to extract tarballs directly when we infer it from the header.

I hope it all makes more sense now!

[alexanderankin]

yep sure does, thanks!

[a962332430]

how to resovle this problem? @marc0der when i try to install a certen java vsersion, got pending like this: see the temp download path, The temporary file size is skyrocketing. How should I resolve this?