Powershell really is crippled by default, unlike bash. Your equivalent is only equivalent (the sudo part) if you start powershell with 'run as administrator', which you probably shouldn't, but it's quite common practise because Windows doesn't have a good, convenient equivalent to sudo. Luckily you can install one with 'scoop install sudo'.
Note you don't need to run as admin to install scoop--it's all about installing stuff for your user account without requiring elevation.
You are right though that you probably shouldn't just run scripts like this if you don't trust them. I do it all the time because it's convenient and I'm not running elevated. You can always check the source if you're not sure.
PowerShell is designed for Windows/Exchange administrators and SQL Server DBAs, and not really any one else. It's powerful when used by those roles due to all the time spent by Redmond and others developing the commandlets for these specific process. Outside of this problem realm it sucks as a scripting language or a CLI environment.
If I think about it tonight I'll build you a version that checks its own hash, then signs itself if possible. That way your script will have even more reach. No need to be dismissive
Or organisations that don't want Joe user (that includes Joe developer who thinks he understands security but does not) running random powershell scripts off the Internet written by god-knows-who that have access to COM, their AD and local file systems and might just POST it all to some remote web site. Or even ones that download packages off the Internet that may have licensing implications or malicious bundling.
I assume no one is old enough or so far away from reality that they don't remember the hell that was VBA and macros in the late 90's and early 00's?
They're very sensible organisations IMHO.
Theyre not oppressive and to be shunned. They just take data protection seriously.
If you read HN and your organisation treats you like 'Joe user', I'd say you probably feel pretty oppressed.
Scoop is aimed pretty squarely at HN readers, not so much at people that are ok with working at an organisation that doesn't trust them to run programs on their computer.
Some of us work in compliance based industries where its a necessity rather than a choice. We still use what could be considered a favourable stack on HN but we deal with masses of sensitive personal data. We're not oppressed: we're professionals. Big difference.
We trust people to run programs on their computer, just not ones that download other programs and ones that have dubious signing or security policies.
The prevailing attitude amongst startups and even big businesses of blasting everything carelessly with shotguns because it's the latest and greatest needs to die. Quality and therefore trust is suffering.
What about bat files? vbs? exes? they aren't dis allowed by default. If an organization has reason for being very paranoid it should try to ban all of those. But the os default should be to allow scripts to run.
It's not the type of the file but the source of the file that is the issue.
It is also that these sorts of scripts are the source of many untrusted, unsigned and unverified files as well and you cannot necessarily trust the canonical source of them either.
If some random guy gave you some pain killers on the street, would you take them? Probably not. That's exactly what this problem is.
Interesting. I've only every tried Cygwin a long time ago, and I remember it being a pain to use and setup, but it was the only thing available at the time. Is this an alternative to Cygwin? Why should I pick this over Cygwin? (might be a good FAQ entry?)
I think you'd want to pick Cygwin when you want to be able to compile and run POSIX apps on Windows without having to modify them too much.
However, if you just want a better command-line experience on Windows and want to easily install cross-platform open-source programs, I think Scoop is a better alternative to Cygwin.
If that is what you want, then not being a pain to use and setup is one good reason to pick Scoop :)
Also, Cygwin programs can only run under the Cygwin environment, whereas the programs Scoop installs are usually native programs that can be called from any other Windows program, or executed from a normal console. I assume there's a way to call Cygwin programs from a normal win program too--it's just more round-about.
Cygwin programs don't all depend on a Cygwin environment, most of the work occurs at the C library level. Some stuff might want a shell with more or different features than you get with the windows cmd shell.
I'm really curious what the major hurdles to using Cygwin were, at least from an Unix user point of view. I've been using it for the past 6 years or so and I'm quite happy.
These days I feel that the best bet on Windows is to install the 20 or so Windows specific programs that you probably use + Cygwin.
Nice project, I think this was very much needed for windows. Having a proper shell is pretty much mandatory for web development these days and I think this will help great deal for developers who would prefer windows.
Completely unrelated but you might want to silence the parts where you type your passwords in the video, some one can easily predict your password by keyboard's click sounds. For example your github password is 7 characters long and contains `w` or `n` in first 3 letters.
Interesting. I used to download and unpack zip files manually from the gnuwin32 SF project until I found mingw-get[1] which downloads and installs packages from the MinGW32 and MSYS projects. Problem with that was it lacked packages like curl which I still had to get from elsewhere.
It seems that quite a number of apps in Scoop pulls from these projects.
From a cursory glance, I can see that scoop is installed in your $env:LOCALAPPDATA path. While Chocolatey is, by suggested default, installed in C:\chocolatey\. This is a plus for scoop since installing in your root is usually bad practice and can make managing your machine more difficult for systems administrators. This also allows a standard user to install applications without administrator approval. (so long as they can execute unsigned PowerShell scripts)
Exactly something that could have been pushed into Chocolatey. The biggest thing about these kind of tools is to add and maintain the packages. Chocolatey has been gaining momentum and has a lot of packages. Now, there comes a new kid in the block.
Fortunately, it's much easier to write packages for Scoop (aka "app manifests"). You only really need to know JSON, whereas with Chocolatey you need some Powershell and Nuget chops.
Wow, this is just as awesome as brew on OSX. I had no idea that there was an alternative to the hideous command prompt. I installed Windows 8.1 on a desktop last week, and this has finally convinced me that it is feasible to use as dev machine.
This seems nice. In fact, this almost does what I've been doing for years through a script. The major functional difference between my script and your otherwise excellent idea is that I try to avoid installing anything. And that is possible for pretty much everything in your list.So please favour portable versions instead of installers. And if possible and only an installer is supplied, please check if you can't get the app anyway by simply unpacking the msi and getting the files out of it.
I totally agree. Self-contained installs without side-effects are the goal for Scoop, and it's almost there. Scoop extracts NSIS/NullSoft and InnoSetup installers already, and if all goes well it'll extract MSI installers soon too (using lessmsi).
If you're building your own package for Scoop and you just want to run the installer, there's good support for that too.
Thank you so much! I've seen that before but assumed the /a 'administrative install' meant UAC popups. Just tried it now (with /qn though) and it's UI-free. Very cool!
That's OK whenever you can do that, but with databases and other such tools; deployment of which involves launching background services, installing logical drivers or some kind of convoluted configuration; it is a little difficult to have them created and maintained as portables.
Out of curiosity, is there anyone here who uses the virtual machine approach to get unix tools onto Windows? Wouldn't that work much better?
I'm currently using OSX as my development os and I would like to switch to Windows because I do a lot of hardware hacking and often drivers are Windows only. The only things that holds me back are battery life (about half compared to OSX) and command line tools.
Sure, VMWare Player with a shared folder pretty much lets you act with a shell onto a (Windows) directory. I don't know how much this helps you with hardware evelopment though.
Yes that's true for common programs like less, tail, grep, awk, and sed. I do think Scoop can give you better support for ln and sudo though. Then on top of that, Scoop lets you install Ruby, Postgres, Figlet, Go, Vim etc.
For a lot of GNU core utilities, Scoop uses the same MSYS programs that come with MSYS Git, it's just installing them separately so you can choose only the ones you need.
It's incredible and useful because there are some others like me, who would rather reboot to Ubuntu/Fedora/etc just to avoid the hostile developer environment of windows, even for small tasks.
There is a severe lack of good commandline utilities. The ones that exist, require so much effort to set up. Just because it is possible to develop on Windows since 1992 doesn't mean it is a pleasant experience to do so.
That's fine but you can still install stuff and leave it. It's not hard.
For ref, I'm currently fixing something on a Windows NT4 VM in Visual C++ 6 for a client (they are tied to this configuration before you ask). I've had this VM for 11 years. Haven't set anything up since then apart from apply a couple of hotfixes.
I'm also, whilst the above is compiling which takes a while because it's huge, editing our python VCS hook scripts on a Ubuntu machine in vim.
They're both shit and wonderful at the same time (in similar ways).
Author here. I use Chocolatey too, although not so often recently.
Scoop is more focused on open-source command-line developer tools. I expect Scoop will appeal more to cross-platform developers, those who appreciate a bit of Unix philosophy in their spare time, and those who feel 'stuck' on Windows.
Chocolatey does a lot of things that Scoop will never do, like install Web Platform Installer apps, and built-in Windows features.
So I need to write chocolatey packages for non open source stuff? For example, I was about to add a package for Teamcity. So scoop doesn't encourage that kind of tools / software? Btw, I am not being critical of the tool. It is great that Windows is getting some much needed tools like this.
The 'extras' bucket for Scoop is a good fit things that aren't open source command-line tools, but are still useful dev tools. Teamcity should fit well there:
>Note: if you get an error you might need to change the execution policy (i.e. enable Powershell) with set-executionpolicy unrestricted -s cu
The Windows equivalent of curl | sudo bash...
Please don't do this. Sign your Powershell scripts.