Also, it's worth checking out even if you don't care about WGET. This is some great frontend functionality that's easy to follow and remains connected to the fundamental command line functions. I can see uses for everyone from beginners to experts.
Whoever came up with this is doing something that I hope others mimic.
Also, it's worth checking out even if you don't care about WGET. This is some great frontend functionality that's easy to follow and remains connected to the fundamental command line functions. I can see uses for everyone from beginners to experts.
Whoever came up with this is doing something that I hope others mimic.
there's also a GUI for FFmpeg there but maybe there are other programs that already serve this purpose
https://chocolatey.org/packages/Wget/1.20.3.20190531
(download from left side "Download" link and rename 'nupkg' extension to 'zip' for easier extraction; then look in the 'tools' folder for the appropriate bitness archive)
Wget current Windows build is still v1.20.3 (upstream changelog appears to be obsolete; Windows repo has {mostly} been live at https://eternallybored.org/misc/wget/).
[v1.20.3:] OpenSSL 1.1.1b, ZLib 1.2.11, gpgme-1.13.0, pcre2 10.32, libpsl 0.20.2, taskbar progressbar, Windows certificate store support, manual; the binaries have been updated and now work fine with SSL connections.
Item posted by Darshit Shah <darnir> on Fri 30 Nov 2018 12:14:38 AM UTC.
Noteworthy Changes in this release:
Add new option `--retry-on-host-error` to treat local errors as transient and hence Wget will retry to download the file after a brief waiting period.
Fixed multiple potential resource leaks as found by static analysis
Wget will now not create an empty wget-log file when running with -q and -b switches together
When compiled using the GnuTLS >= 3.6.3, Wget now has support for TLSv1.3
Now there is support for using libpcre2 for regex pattern matching
When downloading over FTP recursively, one can now use the --{accept,reject}-regex switches to fine-tune the downloaded files
Building Wget from the git sources now requires autoconf 2.63 or above. Building from the Tarballs works as it used to.
Re: Wget & Curl for Windows
Posted: Tue Nov 10, 2020 2:59 pm
by vevy
I think it is high time Wget and cURL got their own separate threads. That's like having a thread for "Chrome and Firefox" or "Windows and Linux Discussions"!
Re: Wget & Curl for Windows
Posted: Tue Nov 10, 2020 4:30 pm
by webfork
vevy wrote: ↑Tue Nov 10, 2020 2:59 pm
I think it is high time Wget and cURL got their own separate threads. That's like having a thread for "Chrome and Firefox" or "Windows and Linux Discussions"!
Looking through the thread and seeing a little too much overlap between the two programs. Several posts list details on both (including the first) so I'm not sure I can separate them.
Re: Wget & Curl for Windows
Posted: Wed Nov 11, 2020 6:16 am
by Midas
As they are closely related, I see no issue with having a common thread for wget and curl -- let's see if there's really a need for separate threads before taking any measures...
Re: Wget & Curl for Windows
Posted: Wed Nov 11, 2020 7:07 am
by vevy
They are closely related but definitely distinct with different syntax and release cycle and every other thing. I think it's better to look at it the other way around: if they already have 3 pages of content, is there a good reason to leave them to intertwine further and be even more complicated to separate?
@webfork, maybe ignore the release update posts (leave them in either topic) since they are useful as a heads up at the time of release.
Re: Wget & Curl for Windows
Posted: Wed Nov 11, 2020 10:51 pm
by webfork
vevy wrote: ↑Wed Nov 11, 2020 7:07 am
They are closely related but definitely distinct with different syntax and release cycle and every other thing. I think it's better to look at it the other way around: if they already have 3 pages of content, is there a good reason to leave them to intertwine further and be even more complicated to separate?
It's not a question of should we separate them (that would obviously be better) but can we? Generally speaking, there's a good reason to give entries their own space to aid visitors and keep things on topic, and then there's this thread with it's overlapping data and replies. For example, this post that lists both WGET and CURL, including within the referenced URL and contains a reply about another post discussing WGET:
If you've solved this, then by all means give me the answer but keep in mind there's no functionality for duplicate entries in both threads.
Re: Wget & Curl for Windows
Posted: Thu Nov 12, 2020 2:35 am
by vevy
Leave it in Wget. Add it to the mod note: "The Wget thread includes references to a curl build by Moluccas developer TumaGonx Zakkum. For example, see here."
It was also mentioned in the update posts multiple times later. You can put on of those in the curl thread.
It is not the prettiest solution, but it would become even less so otherwise.
Re: Wget & Curl for Windows
Posted: Thu Nov 12, 2020 12:31 pm
by webfork
For those coming in on the tail end of this conversation, if it seems like I'm going on far too long about this, it's because I think this is a policy conversation and not limited to Wget/Curl. In other words, about how threads are handled going forward.
vevy wrote: ↑Thu Nov 12, 2020 2:35 am
Leave it in Wget. Add it to the mod note: "The Wget thread includes references to a curl build by Moluccas developer TumaGonx Zakkum. For example, see here."
It was also mentioned in the update posts multiple times later. You can put on of those in the curl thread.
It is not the prettiest solution, but it would become even less so otherwise.
I don't see the logic here. Even if that were the only problematic entry in the thread that had overlapping content, do you really think adding a bunch of disclaimers to the thread posts really clears up confusion? And that's assuming that topic posters actually pay attention to these notes we add. My guess is that even site regulars will just do a simple search, pick whatever thread comes up first in the search irrespective of what the topic says, and then moderators will have to again chase down and split/merge threads. Rinse and repeat.
I'm fine creating either a separate Wget or Curl separate thread and putting a note at the top of the first post of the old one, but I don't think the goal of fully separate, unique threads that stay in their own lane is achievable. If you poke around on PortableApps.com's forums, you'll see we're not the only ones with this kind of topic bleed.
Re: Wget & Curl for Windows
Posted: Thu Nov 12, 2020 12:37 pm
by vevy
Even if one thread is titled Wget and the other cURL?