Another fun one is Extract-Archive which is painfully slow while using the System.IO.Compression.ZipFile CLR type directly is reasonably fast. Powershell is really a head scratcher sometimes.
Another fun one is Extract-Archive which is painfully slow while using the System.IO.Compression.ZipFile CLR type directly is reasonably fast. Powershell is really a head scratcher sometimes.
I tried to look into the whole Expand-Archive thing, but as of https://github.com/PowerShell/Microsoft.PowerShell.Archive/c... I can't even find the Expand-Archive cmdlet source code anymore. The archive files themselves seem to have "expand" be unimplemented. Unless they moved the expand command to another repo for some reason, it looks like the entire command will disappear at one point?
Still, it does look like Expand-Archive was using the plain old System.IO.Compression library for its file I/O, though, although there is a bit of pre-processing to validate paths existing and such, that may take a while.
That "up to a point" is crucial. Storing chunks in memory up to some max size as you wait for them to be written to disk makes complete sense. Buffering the entire download in memory before writing to disk at the end doesn't make sense at all.
There are smoother ways to deal with this (i.e. reduce download rate by faking dropped packets to output speed), but if you just want a simple download command, I think both simple solutions are fine.
If the download doesn't fit in RAM, it'll end up swapped out and effectively cached to disk anyway.
If you want to download many/large files, you're probably better off with Start-BitsTransfer.
Harassing the creator/team for years because a thing you don't use doesn't work the way you want it to work? That is.
They removed it in PowerShell core 9 years ago! 9 years! And you're still fixated on it!
The alias confuses people that are expecting to run curl when they type "curl" (duh) and also causes headaches for the actual curl developers, especially when curl is legitimately installed!
Why the hostile tone? Pretty rude of you to claim I'm fixated on the issue for years and harassing the powershell development team with zero evidence.
Isn’t it disingenuous to claim it is “up to date” when you know there’s a new version and aren’t using it?
> “The alias confuses people that are expecting to run curl when they type "curl" (duh)”
Yes, once, until you learn what to do about it. Which is … just like any other software annoyance. One you think people would get over decades ago.
> “and also causes headaches for the actual curl developers.”
Linux users can’t comprehend that the cURL developer doesn’t own those four letters.
> “It has very little compatibility with the actual curl command.”
It’s not supposed to have. As I said in another comment the aliases were added to be an on-ramp to PS.
Why aren’t you also infuriated that “ls” isn’t compatible with “ls”? Because you use the full command name in scripts? Do that with invoke-webrequest. Because you expect command to behave different in PS? Do that with curl.
probably they can comprehend that MS has a history of making things slightly incompatible so as to achieve lock-in and eradicate competing systems.
Also if any program has been the standard for doing this kind of thing for a long time it's curl, it's pretty much a dick move that someone can't just send a one liner and expect it to work on your system because that is often how you have to tell someone working in another system "yes it works, just use this curl script" and then they can see wow it must be something with my code that is messed up.
No, it isn't. This is what I'm objecting to - this frames the situation in terms of Linux being "the one correct way" to do everything computing, and that all companies, people, tools, operating systems, should do everything the way Linux does - and are dicks if they don't. Not just dicks, dicks to you personally.
Including Linux's 'competitors', they are dicks for including things which help their paying customers in a way that isn't the Linux approved way, and they shouldn't do that because of the demands of Linux users.
This is collectively domineering (everything should be my way!), entitled (I have a say how a tool I don't use, am not developing, don't want, and am not paying for, should work), self-centred (everything which exists should be for my convenience), and anti-progress (nobody can try to change anything in computing for any reason - not even other people improving their system for other people).
That is a framing change which should not go unnoticed, uncommented. It's also common in programming languages where people complain if a language looks a bit like C but doesn't behave exactly like C in every way.
Your arbitrary one liner won't work because Python isn't there. Perl isn't there. `ls` is different. Line endings and character encodings are different. xargs isn't there. OpenSSL, OpenSSH aren't there. `find` isn't there. `awk` isn't there. `sed` isn't there. `/` and `/sys` and `/etc` aren't there. It's a completely different shell! On a different OS!
It's not reasonable to expect that a shell that was designed to not be a *nix shell - because the underlying OS is not *nix - will work exactly like a *nix shell and you will be able to copypaste a one liner over.
It is unreasonable to see some developer trying to create a thing in the world which isn't Unix and take that as them being dicks to you personally. It's also bad to be like "I tried one command in this 'new shell' of yours and without understanding anything it didn't do exactly what I wanted and that's you being mean to me. and I'm still going to be hurt about this in unrelated posts decades later on the internet".
> "my impersonal complaint"
There's a person behind the move whom you are calling a dick. That's not impersonal. And it is rude. I suspect it's Jeffrey Snover, but possibly Bruce Payette or James Truher.
Here I address the wider context in a reply to bryanrasmussen: https://news.ycombinator.com/item?id=46182420