Can’t find output from Wget on Windows 10

2

I run wget URL, it gives a pop-up progress bar in the PowerShell Window, then ends with some status (-v option), but no resulting file.

I have seen multiple previous discussions on this, some saying it should be in the current directory, some in a user home directory, some in a VirtualStore under AppData - but nothing in any of these locations.

This is Windows 10, running from a PowerShell command window.

My session (with fake URL):

PS P:\ftp> wget -v  http://mysystem/image.jpg
VERBOSE: GET http://mysystem/image.jpg with 0-byte payload
VERBOSE: received 70544-byte response of content type image/jpeg


StatusCode        : 200
StatusDescription : OK
Content           : {255, 216, 255, 224...}
RawContent        : HTTP/1.1 200 OK
                    Keep-Alive: timeout=5, max=100
                    Connection: Keep-Alive
                    Accept-Ranges: bytes
                    Content-Length: 70544
                    Content-Type: image/jpeg
                    Date: Sun, 03 Mar 2019 02:09:03 GMT
                    ETag: "11390-531efc...
Headers           : {[Keep-Alive, timeout=5, max=100], [Connection, Keep-Alive], [Accept-Ranges, bytes],
                    [Content-Length, 70544]...}
RawContentLength  : 70544

guthrie

Posted 2019-03-03T02:15:27.130

Reputation: 153

Answers

3

I assume wget is used as an alias of the powershell cmdlet Invoke-WebRequest. Then this should work:

wget -v  http://mysystem/image.jpg -outfile c:\temp\image.jpg

It is nice that some PS cmdlets have aliases that are equal to *nix commands providing the same functionality. But sometime it leads to confusion like here. You aren't running wget here, it is Invoke-WebRequest which is quite similar but not the same.

EDIT

In response to your comment: The code in your post does download the file, but keeps it in memory in the .content property of the WebResponseObject that is returned . It is even possible to save the file from the returned object. Like this:

$ret = wget -v  http://mysystem/image.jpg
$file = [System.IO.FileStream]::new('C:\temp\image.jpg', [System.IO.FileMode]::Create)
$file.write($ret.Content, 0, $ret.Content.Length)
$file.close()

Depending of what is downloaded the type of $ret.Content can vary. The above code works for binary files. All in all the first method using -Output is easier and resolves the binary/text format issue for you.

Gert Jan Kraaijeveld

Posted 2019-03-03T02:15:27.130

Reputation: 238

Thanks; you are right; but not sure how it happened as I did not manually create an alias to a PS command. (PS: I did end up using PS WebRequest directly to download the files.) I think when I installed Haskell Platform, it installs msys and adds its /bin to the path, and that contains lots of nix tools including wget, and perhaps it created aliases to many of them? – guthrie – 2019-03-03T14:24:41.023

Thanks, good job! In any case, it seems odd that it appears to do the download, gives what looks like a successful status report, but ... no file? – guthrie – 2019-03-03T14:26:11.770

1It is downloaded, to memory, not to a file. It is the 'Content' member of the object you posted in your question. I'll edit the answer – Gert Jan Kraaijeveld – 2019-03-03T15:19:57.530

1The wget alias in powershell is put there by Microsoft, along with others like ls, curl, chdir, cp etcetera. They have precedence over commands that are in the path, like in your case. Aliases can be removed. External commands can be called by specifying the path like 'c:\bin\wget.exe' – Gert Jan Kraaijeveld – 2019-03-03T16:02:32.997

Very helpful, thanks. It did force me to look into how to do it in PS; $client = new-object System.Net.WebClient $client.DownloadFile(URL,"C:\tmp\file.txt") – guthrie – 2019-03-03T22:40:57.867

Ditto to what is built into PowerShell. There is no real reason to change the aliases. If you have an external .exe that matches a name of a built-in alias, just use the alias name with the extension, i.e., wget.exe or use the full path to the .exe if it is not in your system path. Running external .exe/commands, requires special attention. This is documented in many places on the web. – postanote – 2019-03-04T06:12:51.960