Repository navigation
Invoke-WebRequest -Save (without specifying the name) #6537
Description
In Unix we have:
curl -O https://github.com/PowerShell/PowerShell/archive/master.zip
# and
wget https://github.com/PowerShell/PowerShell/archive/master.zip
which download the file called master.zip at PWD.
In PowerShell, we have to specify the filename:
curl -O master.zip https://github.com/PowerShell/PowerShell/archive/master.zip
and prints the contents to stdout without -OutFile (or -O, -Ou, -Out, -OutF, -OutFi, -OutFil).
Sometimes target URL is read from resources other than manual input and file names are long, less human readable, and we are supposed to preserve the filenames. That requires extra processing / string manipulation cost, which is bit of an inconvenience.
Please add a shorthand -Save switch to make it less wordy, so we can do:
iwr -Save https://github.com/PowerShell/PowerShell/archive/master.zip
Reacted by Michael Klement, Matthew A Cargile, Ghost4Man and Mr Beedell, Roke Julian Lockhart
Activity
markekraus commentedon Mar 31, 2018
kasper3 This is a commonly requested feature. I have investigated adding something similar and it is possible, but not as simple as one would hope. The value of
Invoke-WebRequestandInvoke-RestMethodis in their processing of output from remote endpoints. As such, much of their code is devoted to that purpose as opposed to downloads. This makes integrating download specific features troublesome.I have been drafting an RFC for the inclusion of a new download specific cmdlet. In the move to PowerShell Core the Web Cmdlets lost their ability to work with FTP and FILE URIs. There have also been asks to support downloading of files over other protocols such as SFTP, FTPS, SCP/SSH, etc. There are other download specific features that have been requested including the one in this issue.
Rather than overload the current Web Cmdlets with download features, I would rather have a separate cmdlet that becomes the primary cmdlet for all file download functionality.
I made an exception with the
-Resumefeature as that was currently a huge pain point and not something users could easily work around. However, for the automatic save path detection/creation feature, I would rather that be held off for the new cmdlet and not included inInvoke-WebRequestandInvoke-RestMethod. I already plan for this to be a default feature that would work like this:The file would be saved in the current path and the automatic naming logic would be very similar to wget.
markekraus commentedon Mar 31, 2018
kasper3 Can you be more specific about what you are trying to do?
It's important to note that making things work 100% like curl/wget and 100% like bash are not the goals of either the existing cmdlets, the new cmdlet, nor PowerShell. It's a different language and a different ecosystem, so things will be different in how they are used, what they do, and how they do it.
But if there is something specific that you think is missing, please be more specific and I'll see if it's something needed or something that is already possible.
The download cmdlet would be downloading files. The current web cmdlets would be for working with output from remote endpoints. They would not have full feature parity between them. If you need remote data in PowerShell and not as a saved file, you would use the web cmdlets. if you needed to download the remote file and save it to disk you would use the download cmdlet. Making the download cmdlet put content to PowerShell output streams would not be its objective.
markekraus commentedon Mar 31, 2018
kasper3
In PowerShell, cmdlets and functions should Do One Thing. Processing the output is a separate thing.
For example. I give you the url
https://contoso.com/getfile?ID=18657357. The download cmdlet will download this and file. But what kind of file is it? is it text? if it is text, what encoding do I use? Do I need to care bout a BOM? How do I determine that? How do I let you override that? Do you need a byte stream? what about a IO Stream?That is a bunch of additional logic to put the file in standard out. The code in this cmdlet would have to stay on top of all the changes in the PowerShell ecosystem with regards to file content handling so that there are no surprises.
However, we have cmdlets that already do that logic and do stay on top of it all like
Get-Content.What I planned for the output of the download cmdlet is to return the item it creates with
-PassThru. then you could domarkekraus commentedon Mar 31, 2018
FYI PowerShell/PowerShell-RFC#124
markekraus commentedon Apr 17, 2018
I'm closing as this is a duplicate of #6618 where there is more discussion on the topic.