Skip to content
New issue

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

Add support for Wget2 #619

Merged
merged 7 commits into from
May 4, 2024
Merged

Conversation

swjzielinski
Copy link
Contributor

Added support for Wget2 in the download.sh script.

It would now also check if "wget --version" contains "Wget2".
If it does, the script will say that it uses wget2 and will omit the --show-progress option that wget2 doesn't understand.
Hopefully, it will work the same way on wget earlier than 2 (testing probably needed)

There's probably a better way to do this, but I'm not experienced enough.

Copy link
Owner

@rockerbacon rockerbacon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you mostly copied the existing wget call and removed the --show-progress option. I found two problems in this solution:

  • --progress=dot has not yet been implemented in wget2
  • The Zenity progress bar is not working because the output for version 2 is different

@swjzielinski
Copy link
Contributor Author

 --progress=dot has not yet been implemented in wget2

True, will remove it for now

* The Zenity progress bar is not working because the output for version 2 is different

I don't think it is currently possible to get it to work with wget2. The file completion percentage just isn't sent to output, not even with --debug.

So, there are several paths to take now:

  1. accept that zenity is broken and only shows empty bar and full bar for wget2
  2. redirect wget2 to curl to have working zenity progress bars
  3. disable zenity for wget2 (with or without the wget2 progress bar)

What do you think?

@rockerbacon
Copy link
Owner

I checked wget 2.1.0 and it sends progress to stdout as documented in its man pages. This is the line I used:

wget 'https://github.com/ModOrganizer2/modorganizer/releases/download/v2.4.4/Mod.Organizer-2.4.4.7z' --progress=bar:force -O '/tmp/wget-test/Mod.Organizer-2.4.4.7z'

@swjzielinski
Copy link
Contributor Author

Ok, I messed around with the grep search pattern, which caused me to not see that --force-progress works.

I can grep the progress bar to output the percentages. I may have too high download speed to see the zenity progress bar change between the values. In any case, I can only see an empty progress bar and then the window closes when the download is complete.
I wrote this script

#!/bin/sh
(
echo "0%";sleep 1
echo "0%";sleep 1
echo "1%";sleep 1
echo "15%";sleep 1
echo "41%";sleep 1
echo "66%";sleep 1
echo "91%";sleep 1
echo "100%";sleep 1
) |
zenity --progress --auto-close

and it does work, but when I run

wget2 https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u312-b07/OpenJDK8U-jre_x64_windows_hotspot_8u312b07.zip --force-progress \
|grep --line-buffered --color=never -oE '[0-9]+%' \
|zenity --progress --auto-close --auto-kill

this is the result: (see attached video)

Screencast.from.2024-05-02.09-12-28.mp4

I tried running the install script with 'DOWNLOAD_BACKEND=curl' and the windows disappear just as fast.

@rockerbacon
Copy link
Owner

It won't work because of buffering. Since there are no line feeds in the wget2 output, the --line-buffered grep option does nothing and grep only flushes output after wget2 is finished, at which point the download has reached 100%.

Try looking into stdbuf, maybe stdbuf -o0 grep --line-buffered --color=never -oE '[0-9]+%' is enough.

There's also the possibility that wget2 itself buffers output (write behaviour may differ when piping into another command vs writing to a terminal), so also take a look at that if stdbuf on grep isn't enough.

@swjzielinski
Copy link
Contributor Author

stdbuf on grep doesn't work, stdbuf on wget2 doesn't work

why did RH think shipping wget2 as wget was a good idea
they didn't even consult with the devs (https://gitlab.com/gnuwget/wget2/-/issues/661)

@rockerbacon
Copy link
Owner

@swjzielinski I've added a generic progress bar in #629 that should work with wget2. Merge it with your changes and let me know if the progress bar works.

@rockerbacon rockerbacon linked an issue May 4, 2024 that may be closed by this pull request
@swjzielinski
Copy link
Contributor Author

Yes it works, thank you :)

@rockerbacon rockerbacon self-requested a review May 4, 2024 14:07
@rockerbacon
Copy link
Owner

I noticed you changed the detection mechanism to look for the wget2 command instead of checking the wget version. I agree that is better, so long as Fedora 40 also has the wget2 command.
I'd suggest for the wget2 command to be checked alongside curl and wget in step/check_dependencies.sh. If some mad lad decides to go wget2 only, the installer can support that.

Copy link
Owner

@rockerbacon rockerbacon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR is good to go as-is, even without the additional wget2 check I mentioned. I'll give you some time in case you want to add that change, but if not we can just move on to a merge and release.

@swjzielinski
Copy link
Contributor Author

swjzielinski commented May 4, 2024

Ok, I pushed the additional check.

so long as Fedora 40 also has the wget2 command

The whole problem was that F40 was shipped with the wget command redirecting to wget2.
I'm actually on F40 myself.

@rockerbacon rockerbacon merged commit 663129f into rockerbacon:master May 4, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JDK is not downloaded to the /tmp directory
2 participants