--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?

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'

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)

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

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.

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)

@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.

Yes it works, thank you :)

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.

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.