I understand your specific security concerns, but the whole line is offensive. Certainly not the fault of the Chocolatey authors, but this is what I'd call a massively over-engineered shell:
Except for the "iex" this isn't really Powershell specific - it's just instantiating a .NET framework object and calling a method on it. It might as well be C#.
No it might as well not be. One of the big complaints about powershell is how unclear the command line syntax for tools tends to be. A big part of developing a good C# API (or any for that matter) is clarity, readability and understanding. One of the reason fluent APIs are popular. Bad is bad, don't blame .NET or C# for that.
And yeah I realize you can come up with an ugly command line example in just about anything. But powershell tends to be one of the uglier ones out there.
If you happen to have wget, sure. Windows doesn't, by default. It is far more likely that the machine will have powershell, and if it does, it has the .net frameworks.
Because you are installing programs on your computer from a "shortened URL", which could point anywhere. Your examples use a URL that is the final destination so you can make an informed decision whether you are willing to trust that URL.
If you use the "append a +" bit.ly feature, you can check where it ends up, but not everybody knows to do that.
https://bitly.com/psChocInstall+
A non-shortened URL can point anywhere as well. The only way to "make an informed decision" is to put the URL in your browser—that goes for shortened and non-shortened URLs.
If I were to attack someone with such a scheme, I would take care of serving clean files to a web browser (say, with the user-agent string) and the infected files to command-line invocations. :)
With a non-shortened URL you have one attack vector, hack the website. With a shortened URL you have two attack vectors, hack the website or hijack the shortened URL to point to your own server.
This looks like a close competitor to CoApp (http://coapp.org/) - both are FOSS package managers for Windows, although it appears Chocolatey places less emphasis on libraries and other developer-focused packages. That is, CoApp is emphasizing shipping both source and binary packages, and provides more help to package maintainers still trying to make their programs build on Windows.
Chocolatey will probably get more users early on though, because of its association with the ever-popular NuGet (watch for the Scott Hanselman blog post...).
Differences between PowerShell and other *nix shell variants are that PShell allows you to pipe full COM or .NET objects between processes or commends, rather than just piping the text files between different commands.
PowerShell vs cmd.exe PowerShell is actually a complete shell scripting language, that gives you full access to all of the .NET libraries and methods. It also has a rather nice IDE that ships with Windows as is. Also, you can use PShell of Exchange and other server automation, you can do remote scripting, and it has some pretty decent security controls baked into the system.
> PShell allows you to pipe full COM or .NET objects between processes or commends, rather than just piping the text files between different commands.
Which is IMHO the best part about unix shell and the worst about PowerShell: being pure text, unix shell allows for very loose definition of the interface between the program and outside, allowing to connect stuff in creative ways with minimal plumbing; whereas PowerShell makes this interface definition quite stringent by comparison, hence needing theoretically less plumbing (at least for simple tasks) but requiring far more design in the interface, restricting connectivity which in turns generates more mediation and plumbing to connect foreign elements.
In short unix shell may seem archaic but its loose binding makes it very powerful and quick to solve problems, while PowerShell is, well, a chore.
I haven't used PowerShell (since I don't use Windows), but when using the Unix shell interactively every so often I find myself in a situation where the data is too complex for a shell command to be able to process it, or else running into some corner case of missing functionality. Usually I end up piping into python -c, but that ends up pretty gross... if PowerShell isn't the answer, what is?
I wonder how far you could get by sort of plopping PowerShell onto the Unix shell and supporting both structured and text data.
(Incidentally, one such corner case is summing a list of numbers - this sounds like it should be a short command, but actually requires a complicated command line using awk.)
Yes, it's okay if it's started once, but if you have to run it over and over then it's not. For example run it 10000 times, and if time it takes 300ms - you are looking at an hour of execution. Some apps (even if they are big) are just naturally cached by the OS in the file system buffers, but others are doing quite of other things before running.
If this is going to be a "shell" replacement it needs to start very fast at least in hot mode (cached).
From what I remember it has an object oriented style, i.e. you don't have to parse text for a specific column you want (you call the appropriate method).
And you also get easy integration with the .NET libraries.
There are also lots of libraries for powershell that make it very easy to do things. For example MS provides a great way to manage Exchange via powershell. You can even go so far as getting a GUI in powershell.
As a sysadmin I use powershell for quite a few automation and management tasks on Windows servers. It is nice to have a interface to the server that I know will always be on the server and will update by itself. There is no need to install a third party scripting language just to script simple things that are difficult to do in the standard windows command line.
'ls' has -R too, if you really want to do it like that.
Of course, that form in Unix would not be suggested, because there are other far better (readable/concise) ways of doing that. (like the 'find' one someone else just gave you).
I had high hopes when I saw the title. I was expecting something for getting MinGW precompiled libraries like openssl, curl or boost; which I find needing more than often.
I am using the vanillia one and it is very good. The only problem I have with it is that I have to compile everything for it. Sometimes doing so is not so straight-forward and can take a lot of time, boost being one example.
Yes, that's true. But I need a sane build environment with development packages. I would like to be able to compile against libcurl and openssl as easy as it is on Ubuntu or Fedora. Something like Cygwin but without the GPL requirement on final builds.
I think CoApp is going to be the answer for what you are trying to do. Chocolatey starts after compilation. If someone is already providing libcurl and openssl, these are easily offered as choco packages. Once CoApp comes out, it's highly likely that there may be some integration with it.
