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

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.


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)

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.

  • 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 Mar 3 '19 at 14:24
  • 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 Mar 3 '19 at 14:26
  • 1
    It 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 Mar 3 '19 at 15:19
  • 1
    The 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 Mar 3 '19 at 16:02
  • 1
    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 Mar 4 '19 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.