The Portable Freeware Collection Forums

billon wrote: ↑Mon Jan 07, 2019 4:20 pm elGUI4Wget

nice GUI

bitcoin wrote: ↑Tue Apr 09, 2019 8:29 pm nice GUI

Yeah the image was broken for me, not sure why. The direct link fixes whatever issue: http://guerilla.bplaced.net/elGUI4Wget.png

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.

webfork wrote: ↑Fri Apr 12, 2019 6:12 am

bitcoin wrote: ↑Tue Apr 09, 2019 8:29 pm nice GUI

Yeah the image was broken for me, not sure why. The direct link fixes whatever issue: http://guerilla.bplaced.net/elGUI4Wget.png

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

Curl v7.65.0 released, dated 22 2019-05-22 (changelog and downloads at https://curl.haxx.se/changes.html).

EDIT: relevant portability snippet from Curl manual ('> curl --manual').

On windows, if there is no _curlrc file in the home dir [i.e., '%APPDATA%'], it checks for one in the same dir the curl executable is placed.

Jernej Simončič Wget Windows builds official repository (https://eternallybored.org/misc/wget/) is unreachable, ATM.

Alternative download locations:

• 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)

• http://sourceforge.net/projects/tumagcc/files/
  (obsolete v1.19.4! Bundled with curl & aria2 in '7z' archive)

• https://www.softpedia.com /get/Internet/Other-Internet-Related/WGET.shtml
  (obsolete v1.5.3.1!)

Curl v7.68.0 released 2020-01-08 (changelog at https://curl.haxx.se/changes.html).

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.

Quick note with a pretty straightforward recipe for creating local mirrors of online sites using wget:

www.guyrutenberg.com /2014/05/02/make-offline-mirror-of-a-site-using-wget/

In a nutshell:

BTW and due to the patchy update pace, it hasn't been mentioned here that the last upstream changelog for wget (v1.20 released 2018-11-30) is at http://savannah.gnu.org/forum/forum.php?forum_id=9310.

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"!

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.

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

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.

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:

viewtopic.php?p=75488#p75488

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.

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.

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.

Even if one thread is titled Wget and the other cURL?