PowerShell is open sourced and is available on Linux | Hacker News Reader

PowerShell is open sourced and is available on Linux

azure.microsoft.com

1,217 pointsplatz760 comments

PowerShell is my guilty pleasure of the computing world. Once you've piped strongly-typed objects around between your shell commands, text scraping seems barbaric by comparison. The problem, of course, is that you can't use all that power for much, since the pool of PS-compatible tools and utilities is much shallower than it is for Unix shells. I'm really hoping this will help spur a new wave of PowerShell-compatible tools.

Come to the dark side, we have (strongly-typed) cookies.

After a number of years using PowerShell, my conclusion is the opposite: text "scraping" is just better for most cases.

Normal shell usage means doing a lot of one-shot pipelines incrementally. This is just easier and faster to do when passing text around because you can look at it and not have to inspect some object for it's type and what attributes/methods it provides. Parsing the text is not the problem here (although many people think it is), reasoning about what we're trying to do is.

And the over-verbose syntax doesn't help.

I compare this to human languages. It would be tempting to create a language with minimum ambiguity and clear cut concepts, but it wouldn't be practical. I guess PowerShell as an interactive shell is somewhat like this.

For automation, PowerShell is nice. The language sits between a shell script and going the Perl/Python route, but I still prefer shell scripts for simpler things and Perl/Python for more complex tools.

Having said this, PowerShell is the only sane choice on Windows and has made my life easier by no small amount. I never enjoyed managing Windows servers with their focus on GUI tools and their terrible CLI. PowerShell changed that and even "invaded" products like SQL Server and Exchange making them also nice to manage.

I'm not entirely convinced that "plain text" is "simple." For one, utf-8 is a variable-length encoding, which can cause all sorts of subtle bugs and sometimes leads to security issues because somebody failed to parse a character correctly somewhere. On top of this, using plain text means that every program has to choose its own control characters, essentially an encoding within an encoding. This is great for readability, but it's not always easy to know how a certain program will treat certain corner cases, or even really just at all. I'm not sure what you mean by "you can just look at the text," because unlike something that encapsulates functionality alongside the data, text input into a program might do anything.

> Normal shell usage means doing a lot of one-shot pipelines incrementally.

Sure because no-one ever takes those "one-shot" pipelines full of `cut`s and `grep`s and distributes them in real products. /s

As far as I can tell, Powershell is designed for scripts that are meant to be distributed, so they must be robust. Normal 'text scraping' Bash is shit at that.

> text "scraping" is just better for most cases.

Unix pipes handle bytes, not just text. For instance, copy a hard disk partition to a remote hard disk via ssh:

  (dd if=/dev/hda1) | (ssh root@host dd of=/dev/sda1)

The KISS principle ("Keep it simple, Stupid") is the best way in many cases. In Unix you can quickly enter a pipe without special coding which does also non-trivial stuff. For instance,

  find -name "*.xls" -exec echo -n '"{}" ' \; | xargs xls2csv | grep "Miller" | sort

gets a sorted list of all entries in all Excel files which contain the name "Miller", no matter how deeply the files are located in the directories. Can you do this in Powershell quickly? I don't know, I am actually curious.

Objects in pipes are convenient and powerful. However, for most applications of pipes they are probably overkill. If things get tough you can simply use files rather than objects.

I would not be surprised if many Windows users will prefer bash pipes from the Ubuntu subsystem in Windows 10 rather than Powershell because it is much more handy for most pipe applications.

> I compare this to human languages. It would be tempting to create a language with minimum ambiguity and clear cut concepts, but it wouldn't be practical.

Lojban[1] is usable in practice (though that may be because it still allows you to be ambiguous when desired).

[1] http://lojban.org

> And the over-verbose syntax doesn't help

This is basically the reason I have not been willing to put any time even trying to learn ps. I mean, trying to translate

unzip file.zip folder

To ps was a nigthmare. Like:

[System.IO.Compression.ZipFile]::ExtractToDirectory($zipfile, $outpath)

I don't _want_ to learn to type stuff like that for simple shell scripts.

This is all a big part of the reason why I personally advocate using a standardized text-based object serialization format (like YAML) for these sorts of things. In particular:

* Still text based and human-readable, which helps for debugging/troubleshooting * Still text-based and machine-readable, so it's inherently cross-platform (assuming that all said platforms agree on their text encoding) * Still less troublesome than piping arbitrary text through `grep` or `sed` or `awk` or what have you * Still provides the "everything is an object" benefit that's lost with arbitrary text streams * Still orientable around streams of data, at least for YAML (by using the document delimiter)

Passing CSV around can be a useful middle ground, if you're using utilities that all do proper escaping and allow newlines in strings etc., such as csvkit.

As a note, there have been strongly-typed shell languages for Unix for some time. Scheme Shell[0], Turtle[1] and TCSH[2] leap to mind; but there's nothing preventing a developer from using Perl, Python, Lisp or any other language that allows itself to accept stdin as an interpreted script.

0: https://scsh.net/

1: http://www.haskellforall.com/2015/01/use-haskell-for-shell-s...

2: http://www.tcsh.org/Welcome

Edit: oh my, I posted the wrong link for tcsh. No one noticed, but my apologies nonetheless.

This is why I find PowerShell to be an answer to a question nobody asked. If bash/zsh isn't cutting it for you, drop into something like Python, Ruby or Perl to do the heavy lifting.

PowerShell will never accumulate a library as comprehensive as what any of those three have, each has had decades to accumulate packages of all kinds, and more are still being added.

It's odd, but not surprising given their history of "Not Invented Here", that Microsoft never even considered using Python or Ruby when they both have .Net implementations. Their enthusiasm for JavaScript wasn't sufficient for them to embrace that either.

0: scsh is a nice scripting language, however it's not meant for interactive usage (PowerShell is) See: http://www.alphanet.ch/~schinz/scsh-faq/scsh-faq_4.html#SEC3... Scheme is also dynamically typed.

1: It's the first time I see it, but from a cursory glance and some docs (http://hackage.haskell.org/package/turtle-1.0.0/docs/Turtle-...) I think it doesn't include simply calling external commands (I couldn't find any info on how to wrap an external executable with type, too). Without this, it can't be a real "shell", only a scripting DSL for Haskell. It's not very good for interactive use as it relies on ghci.

2: tcsh is meant for interactive use and is a shell; I used it when working with FreeBSD but never wrote any scripts in it. However, I don't see any mention of types in it's manual (other than file types): http://linux.die.net/man/1/tcsh

PowerShell is statically typed like Turtle, has a nice scripting language like scsh and is meant for interactive use. It's not only typed, but also (partly) object oriented and with full and direct access to all .NET/Mono classes. That also implies that you can write commands in any of the CLR-targeting languages, by the way, like F# or Clojure-CLR.

PowerShell is unique (not literally so, as I'm sure there are other projects doing similar things, but I think it's safe to say that it's unique among widely used shells) in what it provides and in that it takes all that into interactive use. It's definitely worth checking out if you haven't already. Of course, keep in mind its problems, like the mentioned smaller number of already available utilities.

I want to throw my support behind scsh!

It's useful for those things that cross the boundaries between a program, and a shell script. I've found once you need functions for a shell program, it's time to step up to scsh.

I also wish scsh ports were more well maintained so people could use their favorite schemes with scsh syntax, but it's quite a large codebase to port, so remember that it's scheme48 scheme.

There is also Ammonite Shell[0], XONSH[1]

0: http://www.lihaoyi.com/Ammonite/#Ammonite-Shell 1: http://xon.sh/

I've been loving using Node.js for scripts. You get all the NPM goodies plus STDIO, and they end up working just as well as shell scripts.

One of the big advantages IMO is that I only need to master one language for all of my needs, from browser to server to shell :)

I agree... though my default reach-for these days tends to be node. I don't much care for ps, even if it's now available on Linux, I just don't see myself using it much... I like C# a lot, and even other .Net languages. But I don't like all the extra typing for one-off scripts, even if they do get re-used.

I can paste various commands for other terminals/environments in a tweet, the same can't always be said for ps. It's just a lot of typing.

There is also GNU Guile, with a fantastically easy to use FFI. Has a great manual too.

I've never seen tcsh referred to as strongly typed. Could you elaborate?

I love the strongly-typed cookies but I absolutely hate the powershell syntax. It's like C# and Bash got together and had a really ugly baby.

As long as you bear in mind that it's main purpose is a usable replacement for the CMD.EXE batch language, then you should be willing to forgive Powershell it's warts.

Except that they added a bunch of new warts that don't have any relation to CMD.EXE. They took the opportunity to re-invent how a shell works from the strongly-typed object perspective but then they copied some of terrible syntax of 40 year old unix shells. I just don't understand it.

I'd rather write scripts in pure C#.

I would hope it's also meant to put vbscript out to pasture as well.

In my admittedly limited experience there seems to be at least 3 aliases for every keyword which makes reading someone else's code a real hassle sometimes. Our ops guys swear by it though.

You're supposed to avoid the aliases in scripts. Or that's what's recommended anyway.

The implicit return semantics are insane, since you can implicitly early-exit when you do things like call ArrayList.Add (which returns a bool to indicate whether the thing was added).

Yeah, I wanted to switch to PowerShell but then I had to call an exe with variable arguments from the PowerShell script. That was a quick way back to cmd.

Yeah, it's a mixture of Perl and Bash with sudden C# calls interspersed.

Is this really so useful in practice? I have never used PowerShell before (nor do I have plans to do so in the near future), but I would imagine the downside is complexity, both for user and especially for developers. With text you just read and parse, while with objects you need to know the object type, its fields,... Whatever happend, I hope text stays here (and I have a bad feeling about it ever since I met systemd).

Could you elaborate on what the actual complexity is, rather than what you imagine?

For a developer writing a tool, exposing an interface as objects is far easier than having to constantly serialize data into a string. Keep in mind that once you serialize data into a string, you can never change the order of the data or else other tools will break. Not so with a object based interface.

In other system-admin type tasks PowerShell hides complexity. For e.g. finding the IP address of a network interface is simply

  Get-NetIPAddress | select IPAddress

compared to something horrendous like

  ifconfig | perl -nle 's/dr:(\S+)/print $1/e'

> With text you just read and parse, while with objects you need to know the object type, its fields

parsing is actually a huge pain in general. a lot of unixy tools produce different output when their stdout is not a terminal to be more pipeline-friendly. That output is generally easier to parse (often tab-separated or so), but you still need to know the same things about the output (the "type" could be whether it came from `ps` or from `ls`, and the fields are just in some static order that was usually chosen decades ago, and if it's extensible it's cumbersome).

If `ps`, `ls`, etc produced typed output, I would be sooo happy.

When I worked at google I thought about what it would be like to have a unix userland where all the parts communicate with protobufs instead of raw text. There are some problems (like portability of message definitions, which was a solved problem within google, but which is harder when you have multiple parties/entities/companies contributing message definitions).

edit: accidentally a word

I find it massively useful in practice, even for mundane tasks.

For example, the other day I was trying to search the columns of a very large SQL Server table¹ but also needed information about the column type.

  …\dbo.site> ls Columns | select Name, DataType, {$_.Properties['Length'].Value} | where {$_.Name -like '*int*'}

  Name            DataType $_.Properties['Length'].Value
  ----            -------- -----------------------------
  internal_end    datetime                             8
  internal_start  datetime                             8
  interval_code   varchar                              5
  prod_intv_start int                                  4
  prod_intv_stop  int                                  4
  working_int     decimal                              5

Quick, easy. In a *nix shell that would be very tricky.

¹ SQL Server installs a Powershell extension so that you can essentially treat databases like a fancy object filesystem. It's wicked cool actually.

Objects are discoverable in powershell. Enter the object, and lists the object out as text.

Yes, it's quite useful in practice, because the alternative is knowing exactly the format of text some command is going to produce and munging it, which is hardly better

It's nice when it works, but it's a pain to write a command-line utility that outputs into objects. Whereas in Unix, everything automatically outputs into text, so you have to work hard to prevent it from being chainable to the system.

There are also details of Powershell that are very annoying, such as the lack of < redirect, and the difficulties it has on binary output sometimes.

Pipe anything to Get-Member. For example:

(ls)[0] | gm

will list every field and its type on a File object. Wicked easy.

It's not about complexity; it's about robustness, and avoiding insane hacks like this:

    REASON=$(echo "$line"|tr ' ' '\n'|grep reason= |cut -d= -f2)

I've done some Powershell work in my brief time as a Windows sys-admin. I personally struggled with it. The object interaction can be complex and the naming feels less scriptable and more directly out of the C# world.

That being said, I can see the appeal and I know people who love it. I have seen some amazing shit written in it, like this security tool that was just open sourced this year:

https://github.com/adaptivethreat/bloodhound

I have used Mono/GTK# for years on Linux and prefer it over other GTK wrappers. Powershell might be worth a try on Linux, but it will take time to build up the libraries and wrapper needed to interface with most of the Linux subsystems (unless Microsoft as ported a lot of useful stuff in this initial release).

People don't (or shouldn't) use bash/zsh/fish for really complicated stuff anyway. I have a feeling most sys admins/devops people will continue to use Python/Ruby for complicated tasks; and they both have a ton of libraries that help avoid the stdin/out/parsing situation you have with chaining together regular shell scripts.

I really hope this drives a new wave of experimentation and development in shell interaction. Text as the lowest common denominator will never go away but having more powerful constructs available will be great for a lot of use cases.

Check out the language I wrote for that exact use case: http://tkatchev.bitbucket.org/tab/

I wonder what's the difference between an object-pipable shell and a lisp machine (only 10% troll here). Kalman Reti said that passing pointers as IPC meant zero perf penalty btw. Text serialization has design value sometimes, but the amount of cpu cycles allocated on string munging seems flabbergasting.

> Once you've piped strongly-typed objects around between your shell commands, text scraping seems barbaric by comparison

This is why Powershell is a great thing on Windows. Windows works with .Net objects and Powershell works directly with those objects.

It's also why I don't see the reason to be excited that it can run on OS X and Linux now, because neither of those systems work by passing .Net objects around. You parse text with bash/sed/awk/perl/python ... because *NIX works on text based config files and commands that output text.

> Windows works with .Net objects and Powershell works directly with those objects.

I'd say COM, WMI, and the registry are more prominent parts of Windows itself than .NET is. However, PowerShell seamlessly works with those as well.

I'm assuming that the Powershell port includes some subset of the standard cmdlets, which will handle serializing to and from objects.

Strongly typed cookies you say..

Maybe we all can just write our scripts in Haskell and eat some delicious type cake!

Along the same lines, for Linux and MacOS: https://github.com/geophile/osh

Interesting, nice work

"text scraping seems barbaric by comparison"

"can't use all that power for much, since the pool of PS-compatible tools and utilities is much shallower than it is for Unix shells"

The explanations are obvious though... aren't they. Text might be barbaric, but every programming language in the world makes sending text to stdout dead easy. The unix shell utilities are smart to support that case.

Elixir's REPL (iex) makes a surprisingly-good environment for "pip[ing] strongly-typed objects around between your shell commands." It could use a form with added convenience magic, the way Pry is for Ruby, but I've managed to do some decent interactive ops work on systems through an Erlang-remote-shell (remsh) connection to an IEx shell.

IIRC correctly, the major PowerShell push started with Win Server 2008, and headless server mode (no desktop). A lot of WinX sysadmins pissed their pants that they couldn't use GUI's to control everything, and PowerShell was pushed as the way to do server management w/o GUI's (crazy, I know).

I don't think it's too late for PowerShell, I think it's too late for UNIX. You need a big CLR ecosystem for this to play out.

If somebody resurrected Midori as a CLR Unikernel I'd be very pleased.

Care to post a few simple powershell examples that do the sorts of things those familiar with typical nx shell scripting might find useful?

It's junk. Tried to get something useful done and version incompatibilites and poor documentation made it a losing battle. Type theory is over-wrought for getting things done. My boss doesn't care that I have to cast an integer to a string.

I'm hoping this means running EF migration scripts on Linux will be less of a nightmare. It was one of the biggest issues I ran into developing a Web application in .net hosted on Linux.

Powershell is aweful

Back in the day I thought VAX/VMS was amazing. Particularly things like file versioning, however, I had to leave it behind and do things on UNIX (and then Linux) terminals. That change was relatively painless even if I did delete a file or two that I should not have. However, I have moved on and nowadays I would not have a clue how to use VMS beyond typing 'dir'.

If the VMS 'shell' was suddenly available on Linux, despite its 'proven' benefits in various scenarios, I just would not have the working knowledge to get going with it again. Furthermore, there would be no easy answers on StackOverflow to do basic things such as recursively renaming part of all filenames, or batch modifying the content of said files.

The problem PowerShell has for me is that it might as well be a souped up version of VMS (or even BBC Basic). It is not that I am adverse to learning, it is just that I left Windows World a long time ago. Much like my move from VMS to UNIX, there were some good things that I left behind (such as the file versioning thing), however, if you move to a new way of working then there is no need for the old stuff. I appreciate that PowerShell is new, but it does not suit my way of working, i.e. cribbing answers from StackOverflow and tutorial guides.

I appreciate that PowerShell is new, but it does not suit my way of working, i.e. cribbing answers from StackOverflow and tutorial guides.

PowerShell is ten years old and there's 37,000 StackOverflow questions tagged to it - http://stackoverflow.com/questions/tagged/powershell

>We will be extending the PowerShell Remoting Protocol (MS-PSRP) to use OpenSSH as a native transport. Users will have the option to use SSH or WINRM as a transport.

Is possibly an even bigger announcement (this means there's actual momentum behind https://github.com/PowerShell/Win32-OpenSSH)

https://github.com/PowerShell/Win32-OpenSSH/releases

Microsoft has an SSH server for Windows right now.

[Edit] Here is a guide from the WinSCP peeps on how to get it running. https://winscp.net/eng/docs/guide_windows_openssh_server

The native SFTP works well!

This is what I have been waiting for right here!

yup, me too!

PowerShell is interesting, and I don't consider it evil. I know some people swear by it, and I am not one of those people - I'll take my AWK with a side of Ruby/Python, and a helping of SCSH, thank you very much.

It does seem a bit out of place in a UNIX system, though. In Windows, PowerShell ties to a ton of strongly typed databases (SysReg, &c) and windows APIs together into a nice package. But on UNIXes, those APIs are already well exposed elsewhere, and that data doesn't exist. UNIX data is typically stored as text, or can be extracted as such easily. We don't tend to do a lot of binary object munging. I mean, maybe if it integrated with databases, it could at least be handly for dealing with RDBMS scripting, but those bindings are available elsewhere - ruby, perl, python, etc. And MS could build bindings to POSIX, so you'd get a PowerShell version of tools like PS that returned objects, but what are you going to do if you want to munge /etc/fstab, and, say, generate user accounts for all your boot filesystems? I could do that with a line of bash and a few lines of AWK. I don't know why I'd want to, but I could.

So to conclude, PowerShell seems like a neat tool, but it was designed for an ecosystem that doesn't exist on the *nixes.

> But on UNIXes, those APIs are already well exposed elsewhere, and that data doesn't exist.

I'd go with exposed, but not necessarily well. Examples I run into all the time: get an IP from an interface, change iptables entries, even change fstab options. Sure, if you write enough regex, it will probably work most of the time. But it's never going to be as reliable as get_ips('eth0'), or get_filesystem('/tmp').options.add('nosuid').

getting an IP is still pretty ugly, somehow:

  ip address show dev eno1|grep 'inet '|cut '-d ' -f6

But I wouldn't call it unreliable. The cut is the only really nasty bit.

Changing your fstab is easy with a little awk:

  $2=="/tmp"{$4=$4 ",nosuid"}
  {print $0}

Given, it won't remove contradicting options...

> In Windows, PowerShell ties to a ton of strongly typed databases (SysReg, &c) and windows APIs together into a nice package. […]

> UNIX data is typically stored as text, or can be extracted as such easily.

They could ally with the systemd folks in their mission to change that.

Which I’d be very happy about – see also the discussion about getting the ip for an interface above.

Great! So I can now run bash on windows (with WSL), open tmux, and open powershell prompts in each tab: the loop is complete!

I wish powershell's documentation was a bit more clear about what's powershell 1.0, 2.0, 3.0... Etc.

A lot of time I'd find a verbose and tedious way to do one thing because the code was written in "old powershell", when the latest version had a much more elegant solution (either because of new language features or simply more cmdlets were added, removing the need to fall back to some C# syntax)

On stack overflow it often means read more than the chosen answer, somebody would have added a newer way to do it. I wish Microsoft "hey script guy" blog had some versioning info (this post was last updated in 2016, using powershell 3, see powershell 2 version here)

The official cmdlet documentation is versioned, though for some reason it only seems to have versions 3, 4, and 5. Which, agreed is very annoying, since Windows 7 has version 2 by default.

https://technet.microsoft.com/en-us/library/hh849971.aspx

(You should upgrade to at least 3. It has all sorts of useful stuff added! File hashing and web requests at the very least.)

Does tmux work well on Windows? Everything Microsoft has been doing recently with bash on Windows has made me consider buying a surface pro as my next machine.

I have Surface Pro 4 i5 and while I personally love it- I can't really recommend it due to various issues (battery life is shit, sleep is bugridden so best to hibernate only). It's uncomfortable as a tablet, and near useless for the main thing ultra light computers are used - traveling a lot.

I use it at home. The pros are a really tiny size, yet it packs sufficient computing power for many things, awesome screen. I can use it at a desk or grab it to the sofa - but I need to keep the power adapter handy.

If the execution was as flawless as Apple's Ipads are it would probably be the best computer ever (by my subjective scoring which appreciates a pen and sRGB precise screen probably way more than the average user).

But as it is - and I'm comparing it to my Ipad pro which makes all the problems stick out like a sore thumb - it's not an obvious recommendation.

It really is annoying that the battery issues are so persistent. That's the main thing that has kept me from even going to a store to check one out.

I've been stalking /r/surface and I've been seeing complaints about this for over 6 months. Apparently it's more Intel's fault than Microsoft's, but still very disappointing. I love the form factor and I want to support Microsoft lately.

I was a big GNU Screen user on linux, which unfortunately doesn't work on WSL. So I tried tmux, and it works fine for the few minutes I tried it: Create new tabs, detach session, etc.

But once you close the Bash primary window, the session dies, so it's not as persistent as running tmux on a Linux machine, which makes sense given how WSL works. I haven't figured out yet if there is a way to always keep WSL running in the background so that I could close the bash terminal, reopen, and reattach my tmux session.

Execute tmux as a scheduled task.

Tmux came first to cygwin, and now it works on msys2. I don't know about MS-BASH, but MinTTY + msys2 + tmux has been working great for me.

tmux works quite well. I'm less sure about the surface pro :p

I agree, there's been a lot of churn in the PS versions and it makes it hard. Especially when you're new to it and trying to learn.

Yep, in my experience the documentation for Python and really anything OSS far outstrips powershell

Microsoft is projecting that the .NET ecosystem will become a main revenue driver, regardless of the underlying operating system.

Which is why I have no doubt the Universal Windows Platform will become the Universal Platform and be a true desktop/tablet/mobile/server/etc Java competitor on all major OS (mobile, traditional and server).

It must be rather frustrating for Microsoft to look back a decade or more and see they were sitting on the exact technology a hell of a lot of people said would be their future had they made it cross-platform from the start. I remember using C# for the first time around 2004 and thinking "god damn if this were cross-platform like Java it would kill Sun". Back then Microsoft couldn't see past the tip of their nose though.

Yup, I've been playing around with C# more lately and it's such a good language.

Things like embedding with native code is trivial compared to Java. Want to call a delegate(with extras) from a C function pointer? Sure thing, just specify some syntax and away you go. Marshalling strings? Just works.

Totally a breath of fresh air compared to the mess that is JNI.

But that's what .NET wanted to be. That's what Silverlight wanted to be.

IMO this is why Google is currently building a new universal OS from scratch. They know the power Microsoft can yield with this. It will take some time to catch on, but when it does, it's going to be so big.

I think this can be explained by the fact that Microsoft has a long history of trying to kill OSS software and alternatives to it's virtual monopoly in the desktop OS market, killing innovation across many technology sectors in the process. Being cross-platform was the opposite of their goals. They specifically created their own version of open technologies and promoted them as the best/only way of doing things on windows - see directx/opengl, and mictrosoft intentionally degrading opengl performance on windows in order to hurt the OSS community.

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...

Well they certainly have the resources to grow and support the .Net tech stack, that's for sure. I'm finding myself stuck in it more and more.

TypeScript was my gateway drug.

Linux is still my daily driver for getting work done but I can't help but enjoy breakpoint debugging Node applications in VS Code.

Microsoft operates as though, and under the assumption that their software is needed. It's a faulty premise. The presumption is arrogance incarnate.

As a business I can fully, completely operate without any of the their software, profitably, peaceably, and with at least the same amount of friction or less. And more securely.

If you think otherwise, you are ignorant of the tools available for free and of some intelligently thought-out engineering.

Quality of a language is such a trite, over-used discussion that the results/goals of software are completely forgotten. This too is arrogant ignorance.

How many software engineers are there in the world? It's more than taxi-cab drivers. More than Dr.'s More than teachers. Cooks, farmers, and builders (not combined of course). This is evidence of software for software's sake. There is no quality. Just a moving shell-game of "you need this".

I love writing algorithms--that PowerShell and .NET are some kind of something that will solve people's problems any better than something else is simply marketing. I have a pet rock to sell you.

As a Windows Sysadmin, my life would be a living hell without PowerShell.

By giving everything away for free?

The only related revenue stream M$ seems to have left is Azure with some vague notion that giving away their ecosystem will drive people to use their cloud more

Windows isn't free. Office isn't free. All of their enterprise server software isn't free.

Microsoft does not grow food, build houses, create clothes, cars, or protect you from foreign invaders. The basic human needs are not met by MS. The business that claimed that open-source was a cancer is just a marketing company with memetic feedback loops. Plenty of over Operating Systems are out there. Their office product is no longer relevant (vis. a vis. Libre Office, Google Docs, and others). Are you telling me a multi-billion dollar company cannot compete with a startup such as Google? There's a reason why. They do not create. Just marketing.

I'm always in favor of things being open-sourced, but I do kind of wonder in what universe I would use PowerShell when Bash is readily available.

As a full-time Linux user, I have to say that bash is overrated.

For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

Yes, you can customize it a lot, and you can script it but default bash isn't that special to me.

You can use control-O for that, which does "execute this command as if I pressed enter, then when it's done bring up the following command in command line prompt". So if you have a set of commands to run that are 20 lines up in history, you can first find them (with 20x UP or by reverse-search), then just control-O control-O control-O control-O ... to execute them one after another.

Don't forget control-R. I find that even the GP's example of up arrow 20x to be ridiculous when I can type C-r and a few unique letters that were anywhere in the command to find it instantly.

I wasn't aware of this. Thank you.

Not that I've been using Bash and zsh every day for twelve plus years...

Oh. My. God.

Life changing!

Out of curiosity, how did you discover that you could do this?

Doesn't work in bash running in my Terminal.app on macOS, although it certainly does when I `ssh` into one of my Ubuntu boxes. Wonderful shortcut.

EDIT: If anyone knows an easy way to get this working on macOS, I'd love to know it.

> For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

I think the Bash default is better here. If I wanted to run 20 closely related commands, I would make them a single line; far more commonly I want one command from 20 commands ago and then the last command, which is a pain to do on Windows. Much worse is that Windows seems to lose all history every time I close and reopen a command window.

If you put this in your `~/.inputrc` [1]:

    "\e[A": history-search-backward
    "\e[B": history-search-forward
    "\e[C": forward-char
    "\e[D": backward-char

you can start typing a previous command and go up through your history for all commands starting with whatever you currently have typed into the bash shell. Reset the scrolling through the history with `ctrl+c`.

Personally, I hate that powershell remembers your position in the shell history. I don't want to maintain a mental model of the shell history rollodex and where I am in it. That's one less part of my brain that I can't use for thinking about the code. If I have a set of commands to type over and over:

    history 20 | head -10 | sed -r 's/^ *[0-9]+ *//g;' > new_script.bash

* [1] http://codeinthehole.com/writing/the-most-important-command-...

Exactly, but it makes more sense to bind history-search-backward and history-search-forward to <M-p> and <M-n> in my opinion.

The search by previous characters seems to be the default behaviour of FreeBSD's t/csh. Confused the hell out of me at first because Ctrl+R isn't reverse search.

I think I tried something like this once before, and it broke something else. I can't remember what that was, so I'm totally trying this.

For the record - the PowerShell team loves Bash and much of PowerShell is modelled after it. To be fair - we also modelled portions after VMS DCL, Perl, TCL and AS400 CL. There are lots of awesome engineers out there working on different platforms and we learned a lot from of them. Jeffrey Snover [MSFT]

In many bash configurations, ctrl-o is bound to 'operate-and-get-next’. If you hit up 20x, you should then be able to hit ctrl-o to run that command, and your history will automatically go to the next command down. Check it out, it’s great!

EDIT: beaten by pm215!

Bash is 27 years old. It was written to replace the Bourne shell, which is 39.

It is not terribly surprising that a 9 year old tool like Powershell made some improvements over an earlier tool that was already old enough to vote!

I don't see a tremendous amount of accumulated wisdom in Powershell. It may be newer, but I'm not sure they looked at prior art or had design members who were shell gurus in any other shell than `cmd.exe`, which is a horrific shell. Why are commands horrendously long in powershell? If you spend time in the shell, you don't want your fingers falling off due to overuse. Aside... one of the design decisions Microsoft took that absolutely blows my mind is using `\` for file hierarchies instead of `/` when you're writing an operating system in C!

The bash I'm running is actually 3 years old. You make it sound like bash was written 27 ago and no one has touched it since then.

Secondly, what constitutes an improvement is a matter of opinion. For example, I don't see this Powersell as an improvement at all.

Well, it's not an improvement, it's just a different design-choice. I for example much prefer Bash's way of doing it.

Also, Bash does have a way of doing it the Powershell-way, if you want that, as others have commented.

Which is also why I disagree with your statement. Bash may be old, but neither the underlying technology nor the use-case changed much in that time. So, there is not a whole lot where you can innovate with a new tool, at least not for such basic tasks, and instead, Bash has matured throughout 27 years to perfectly fit that underlying technology and use-case that millions of people have.

It seems weird that the feature of PS that you're most impressed with is something so... trivial? You have full access to your history in both shells so you could easily emulate that feature in bash/zsh or you could create a special binding to run all commands from a point in your history so you only have to press Enter once.

I actually think the basic windows command line that does it, as I was never in the habit of installing PS while on Windows.

Or just be sane and use ctrl-r and search.

I get the feeling that most users have only accessed 5% of the features available in their unix shell of choice

I also highly recommend enabling the pgdn/pgup bindings for history-search-forward/backward. If you are searching for a prefix it's a bit easier than ^R.

I do use this too.

>For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

I know other users have addressed this issue in other comments with solutions, but you do know this isn't an issue with Bash so much as it is with readline, right? There are plenty of ways to customize readline/inputrc to make it do what you want. There's even linenoise, if you hate readline for what it is. It wouldn't matter how good Bash got as a shell language, this scenario wouldn't be any easier unless readline also gets a facelift.

I actually did not know that.

Bash is awful. But so are shells in general.

Even Rob Pike says as soon as your shell program gets longer than a few lines, write it in a proper language.

I feel that principle is true from all high-level languages as you move down the chain.

Shell scripts should be 1-20 lines. Python/Ruby/whatever for 20-100 and compiled for anything >100.

When my shell program gets longer than a few lines, it's time to break it into some makefile targets with intermediate files.

I have in the past written a moderate size program in Powershell (installer for a program which needed a lot of configuration for a lot of components and got installed into a lot of different environments). And while that probably wasn't the best approach in hindsight, it wasn't actually that awful an experience.

It's not a million miles off writing a moderate size JavaScript program, except that it has an actual module system.

I wish they hadn't chosen dynamic scope though, nor the silly array result squashing behaviour.

Also the IIS 7 Powershell Provider - that was bad.

(Or a proper language is good too.)

Citation please? I would love to share this with some of my coworkers.

You can use Ctrl+R for reverse search. However, these are minor things... You can find a plugins and what-not to add these kind of functionalities.

I use oh-my-zsh and I'm more accustomed with searching sub-history of commands, e.g. nmap <up> #=> shows flags...

I do that same on bash and zsh since... ever?

It's just default behavior and its customizable for a reason. Different people have different preferences, powershell's default behavior is in no way 'better' than bash's. You can also use a different shell like zsh.

It is just another tool in the toolchest. As you know, on Linux, there are tons of great interactive shells and it is sortof a lifestyle choice. You might want to kick the tires and see whether it fits your lifestyle or not. If you use Bash as your shell, think of PowerShell as you would python or perl - something you write scripts in and call from Bash.

Jeffrey Snover [MSFT]

Thank you for doing this!

Anyone who's done any kind of if else while for in bash/zsh and powershell knows what a relief PowerShell is. I'd love for PowerShell (PSReadline actually) to support the common options of readline- e.g. HISTIGNORE, HISTCONTROL etc

does powershell compile to IL? is it possible to create stand-alone executables from it that do not depend on the runtime?

PowerShell is interpreted, as far as I know. Class declarations may be compiled on the fly, but I've never used them; I'm basically still at PowerShell v3/v4.

We have a hotspot compiler.

We have talked about having it create a stand-alone executable but it has always fallen below the cut line.

Jeffrey Snover [MSFT]

It is about Microsoft being a neutral player in a multiple platform world. Microsoft want people using their tools as it means they are more likely to use their platforms and services. Be it PowerShell on Linux or Bash on Windows or VSCode on macOS they want to make the best tools in the hope that it will push companies/developers towards Azure/SQL/Cloud as that is where the future for MS is.

Windows is on life support and they know this. The future isn't about companies buying hundreds to thousands of Windows licenses but an instance of an OS which is billed per X/month. They have seen businesses are more than happy to enter into such a model with Office 365 and The Cloud so it makes sense for them to move in that direction.

>Windows is on life support and they know this.

How is Windows "on life support"? Desktop/laptop computers are not going anywhere, at least until they invent some kind of VR (and no, mobile OSes like iOS are not suitable for doing real work and managing data in a networked environment the way desktop OSes are). Windows still has at least 90% of the OS market. People and businesses could change to an alternative, but they just aren't, and they aren't going to unless something really drastic happens to force them to (and this would likely have to include many popular applications also providing support for one or more of the alternatives). In the business/enterprise world at least, there is simply no indication that Windows is in any danger at all of losing marketshare or revenue, in fact it's probably going to increase since businesses seem to love the software-as-a-service model.

MS could probably just make Windows free for home users (and make even money on them with advertising and selling telemetry data and also support calls), maybe small business users too, and then soak the big businesses with high fees for their site licenses and SaaS and other services.

Windows revenue has been shrinking for a few years now. The growth is in Azure and related cloud technologies.

Sure Windows probably won't ever go away (until a massive paradigm shift as you mention) but businesses are not upgrading like they once were. You have a mixture of reasons for this, BYOD has chipped away at some of it and forced companies to allow non-Microsoft (i.e. Apple) systems to connect to the network for remote and onsite.

With more and more work being done in the browser it makes specialised software that forces upgrades to Windows out of the picture.

I have worked for a number of large companies and recently the reduction of annual spend on Windows clients is pretty staggering. With almost all "managers" going BYOD with their (mostly) MacBook Pro's and onsite machines lasting a good few years longer than they used to it means we just don't need to buy as much from Microsoft.

You can see Microsoft know whats up as well. Windows Enterprise subscriptions and Azure are the future for Windows in business. For home users Windows is already "dead" from a revenue perspective with the exception of charging via the OEM at first sale. Android, macOS, iOS, tvOS, all the operating systems home users are aware of are free upgrades on supported devices. This is where Microsoft has a problem as obviously they support everything so they can't lock out some users with a "2011 Dell XPS". However going forward I expect we will see them do something along these lines with limitations around what minimum hardware is supported so you will only get upgraded to the latest Windows if you have AVX2 or such based hardware.

I would agree that Windows is nowhere near being on life support but I do think that the size of the desktop OS market is shrinking and that in the future we may see a lot more home computer users move to tablet only or something like a Chromebook.

Enterprise users are much more slow to move but as enterprise SaaS offerings become more robust we may see a lot more businesses move towards a thin-client (a la ChromeOS) and SaaS model to meet their needs. Microsoft is doing the right thing by quickly getting out in front with Office 365. If they hadn't maybe something like Quip or Google Docs could have starting stealing significant market shared but now I don't think many enterprises would bother switching if they can stay with Microsoft.

I wonder the same, but I hope it succeeds.

When PowerShell was written we knew more than when Bash, let alone the original Bourne Shell was designed. Powershell understands that parsing is sometimes hard. Powershell does not invite data-insertion attacks with the the fervour of Bash. In short, it does many things right that would Bash do too if it could be rewritten.

And yet -- I've rarely found it useful in practice. But it's hard to judge that, since I don't do as much in Windows as I do on Unix. So this move will level the playing field a bit, and we shall have a fairer comparison.

Honestly, I prefer the object based approach compared to the text wrangling approach.

I think PowerShell would actually be way ahead of Bash. But we have things so much better than Bash. Python/Ruby let you do a lot of amazing stuff (not shells, I know, but still immensely more useful scripting languages than what you can do in Bash).

Also, if you're still using Bash, I'd highly recommend looking at newer shells. Fish is pretty amazing. I've been using it over over a year. There are others too like Zsh.

I actually use Zsh most of the time, but my point is that pretty much every Linux box has Bash at this point, so I'm a bit curious what Powershell has to offer.

Powershell is really more about the scripting language and the command processing. The "shell" part is modular. On Windows you can still use most cmd tools inside powershell and with its commands.

So you shouldn't give up bash, you should use both and take advantage of the tools that help you get the most done.

What do you know about Powershell? (The answer will depend on that)

Wow. I've been very impressed with Microsoft lately. They could have easily set themselves up as the next IBM, in the sense of being a monolithic corporation relying on corporate practices, but they've been spewing some crazy fun things that shows they're not out of the league yet.

Might just be MY miscontrued perception that microsoft was becoming old/monolithic, but really excited with the direction they are heading.

I speak only for myself.

Microsoft have been hugely focused on hiring people who have experience outside the Windows bubble, and have been encouraging cross-pollination of ideas with the OSS world. There are holdouts for the old guard of course (there's still a BU that requires Windows Phones), but I think everyone knows that the Microsoft of old cannot compete today by bringing an attitude that pleasing the CFO is all that matters. There are techies in the boardroom now who are familiar with the early-mover advantages of free software and the importance of the OSS culture to their workers.

So when a company of massive resources, who can see the writing on the wall, decides to hire thousands of people who actively disbelieve in the value of monolithic lock-in and who enjoy using open-source tools, and empowers them to build interesting things without regard to company loyalty, the result is Powershell on Linux and Bash on Windows. Oh, and a whole lot of goodwill amongst the people you had previously alienated.

Yet that does not prevent them from harassing the linux world with patent attacks. And claim they love linux nonetheless. Thats like shizo behavior.

Well said. If it only happened a decade or more earlier than it did, I think MS wouldn't have lost as many customers.

If only their recruiters were a little more responsive...

Very much so. They're returning to their roots(winning over developers with world-class tools) and it's really refreshing to see.

Between this, VSCode and .NET Core it really is an impressive effort.

Let's hope the awesomeness they are showing on the developer relations side finally leaks into the Windows side and they stop their shenanigans with W10 and Android and VFAT patent threats. It's so disappointing to see this kind of split-brained behavior.

In response to the flagged sibling comment: I use Linux as my main OS and have almost non-stop since ages ago. I have in the past half-seriously wondered whether infamous projects that make Linux worse were MS false flag ops. But here, rather than making personal accusations (regardless of how true they might seem to you), it's probably more productive to provide a counterexample, a reminder of MS's negative behavior, or evidence that they haven't really changed. Then either people can see for themselves, or people within MS will see they still have a long way to go and keep pushing for change from within.

> “Microsoft loves Linux”

Not really sure. Does Microsoft really treat C#, F# compilers on Linux as first-class citizens?

What has MS done to bring MS office on Linux? Alternatively, has it contributed to other efforts like OpenOffice or LibreOffice?

I agree with you! Even if this is all for microsoft's bottom-line (and there's nothing wrong with that since they are a business after all), we all (devs and consumers alike, directly or indirectly) stand to benefit. The prospects certainly seem exciting.

I'm glad that Microsoft is doing stuff like this. But, I can't imagine a lot of Linux users are going to want to use it. As a former Windows developer I always found Power Shell to be lacking in nearly everything I wanted to do on the command line, in fact, I mainly did shell commands on a remote Ubuntu server.

Would you mind elaborating on Power Shell's lack? I've never used it so I'm curious to know more.

I think the most succinct way of describing it is that UNIX tooling is scatterbrained and at times a little ugly, but each command exits because it solved someone's real-life problem. PS by comparison is a set of tools that try to be all encompassing and solve problems MS devs think people will have.

Our PS repository is full of scripts that do nothing but abstract PS into useful high-level actions.

PowerShell's object-passing approach ultimately is a heck of a lot more composable and reusable than the "blobs of text with AWK and SED magic" approach that its predecessors took.

It's somewhat surprising to see people here arguing that the pure text methodology is superior. It's difficult for me to imagine a technically motivated scenario that is improved by having everything dump out inconsistently formatted and specialized plain text.

Great example, ifconfig and netstat. Regular interfaces and an object model over these under the covers is a whole universe better than the ad hoc tabular formats they present.

And now PowerShell on Bash on Ubuntu on Windows is a thing.

(Spoiler alert, it doesn't work very well right now. The cursor keeps jumping to the top of the console and overwriting existing text.)

No, PowerShell on Bash on Ubuntu on a Windows VM on a Linux host is a thing :)

And soon Windows VM's will be able to run inside of other Windows VM's so..... VM's all the way down.

I was just about to try that exact series of steps to see how things went.

If you run it inside of tmux, that issue seems to go away for some reason.

Finally! I love the methodology behind PowerShell. It's more verbose than bash, and that's OK to me. The readability and _consistency_ far outweigh the extra characters. Now, I get that coupled with all the flexibility of *nix tooling.

It's going to be a long road to hook everything up, but this has the chance to finally standardize command parameters.

I'm sorry. This is truly amazing to me and I'm quite excited!

I Can Only See One Problem With PowerShell :)

So, that's kind of the beauty to me. For long lived scripts I can always type out `ForEach-Object { ... }`. When I'm ad-hocing there's always `%{ ... }`.

Bash is a strange beauty, but part of that beauty is how arcane it can be. Generally, people use the smallest parameter possible in scripts instead of the full name. While this can definitely continue with PS, the community has decided on "alias for ADHOC and Full-Name for scripts". This helps the readability tons if someone hasn't memorized all the command parameters.

Powershell is case-insensitive, so feel free to avoid that shift key if you're so inclined :)

Been using PS for a long time and I had no idea about this. Thanks !

It's happy to gobble up whatever improperly-capitalized cmdlets you throw at it, heck you can even forget some letters ;). And with a little tap on that tab key it will helpfully fix your laziness so there's no trace of it in your shell history.

Having powershell + bash on linux lets me compare this way:

powershell, 14 pids(threads?), 3119M Virt size, 80160kb Resident.

bash, 1 pid, 22068kb Virt, 3976kb Resident.

And this is simply starting the process to an idle prompt.

This is on a Debian 8 64bit system. (using their Ubuntu 14.04 binary)

I'm not a huge fan of PowerShell but you're not really making a good comparison here. Bash is "just a shell" that executes commands with a few bits of syntactic sugar here and there to make it easier to string those commands together and perform some primitive logic.

PowerShell is basically an interpreter that works more like a Java Virtual Machine. Consider the hypothetical example that you need to lookup 100 users in an LDAP directory from Bash: You run the openldap command 100 times in a loop. That's 100 processes that need to fork and quit in a serial fashion in order to perform the task at hand.

To do the same thing in PowerShell you'll be calling a native PowerShell LDAP API which will execute all 100 lookups without having to fork any separate process resulting in a vastly faster execution.

It's better to think of PowerShell like the Python or Ruby interpreters. IMHO, PowerShell is a vastly superior improvement to cmd.exe as a shell but on a Unix host it will be inferior to bash for day-to-day tasks.

I fully agree -- they're two different animals. IMHO, it's a symptom of the two different paradigms of running a process on Windows vs Unix.

I worry about getting out of the habit when scripting on Linux of forking off a new process for each iteration of a loop, rather than pushing the loop into powershell, for better execution.

So I wonder how it compares to having the python interpreter open.

According to my machine, running the python interpreter results in 1 PID, 129M virt, 4.6M res.

I'm not so sure it results in a vastly faster execution, at least on OSes which don't need half an hour to spawn a new process. So, yes, of course it was needed for Windows, because there creating a new process is so expensive that sometimes you've got to mortgage your house to do it.

Looked at from another direction, the unix world works beautifully with slim VMs, unlike windows which requires gigabytes of ram. There are plenty of 0.5GB ram unix VMs out there that do their job just fine... and to fork over 20% of that ram just to do shell scripting? Not very portable.

Powershell is essentially running a JVM stlye virtual machine in the background though.

Finally, began learning bash recently, was driving me nuts.. Been more productive on 1st day with PowerShell than I've been with bash in past Month

Cool! I'm having a play with it and it seems to work really nicely. Does anyone know why the following commands don't produce the same output?

    get-childitem | ConvertTo-Csv
    get-childitem | ConvertTo-Json | ConvertFrom-Json | ConvertTo-Csv

It seems like, if there's a perfect underlying data model doing what's effectively an identity conversion shouldn't change anything.

Edit oooo, and all the linux stuff is available within it too. So you can run this to just augment your linux experience.

    ls | grep '_' | ConvertTo-Json

ConvertTo-CSV converts each property into a single string. Rich object? Tough. You get a string. If the type does not support a nice string representation, you get type names, like "System.Collections.Generic.List`1[System.String]" in your CSV output.

ConvertTo-Json serializes in-depth ... properties that are actually rich objects become nested dictionaries instead of simple strings. For instance, the "Parent" which is a Folder object. Recursively, up to the depth allowed.

Anyway, when you convert back, you don't get actual FileInfo and DirectoryInfo objects, you get dynamic property bags. So those complex properties remain dictionaries ... which ConvertTo-CSV turns into strings in a very different way.

If you specify -Depth 1 when you ConvertTo-Json ... the resulting output would be very similar.

I don't have a powershell handy, but one thing that might be causing changes is that json dictionaries usually don't have a defined order (parsing libraries are free to render the keys of a dictionary in any order); are the changes you're seeing just ordering changes?

If you have a Docker Host, you can simply run: docker run --rm -it trevorsullivan/powershell

To clean up the image after you're done:

docker rmi trevorsullivan/powershell

ls and grep are aliases in powershell, so not exactly the same, but pretty close

For your first question: you have converted types. When you did a ConvertTo-Json, you serialized the System.IO.DirectoryInfo type into JSON compatible data. When you ConvertFrom-Json you have a PCSCustomObject.

The conversion to CSV is different for the System.IO.DirectoryInfo than the PSCustomObject. This has to do with the sub-types (converting from objects into serializable JSON objects). It also appears to handle time strings differently as well.

ls is an alias for Get-ChildItem. However, grep is the native command in this case. While such things work to some extent, it has the problem of turning your objects into plain strings. Effectively the same as if you had run

    (ls | % Name) -match '_'

The fact that the file's name is its default string conversion can be pretty annoying when dealing with results, e.g. from gci -recurse where it's quiet important to retain the path to the file. So, careful with such things. On Stack Overflow I tend to scold people who reduce PowerShell objects to strings without good reason ;-)

Powershell is the first language where I managed to save time by writing a program for a task. Needless to say, I'm thrilled at the prospect of using it on Linux. The only thing that I hope they will need to work on is startup time making sure it performs well on low-spec servers (It can be a bit slow starting cold on older laptops).

    ls -Recurse | ? { $_.Name -match ".+docx" }

I am not sure what your example does. How does it differ from

find . -name ".docx"

ls -Recurse | ? { $_.Name -match ".+docx" }

And, if these are the same, why type in twice as many characters as a command? Actually,

ls -R | grep "\.docx$"

is, I think, closer in spirit.

Now, the issue is things further in the pipeline, I imagine. The find solution allows selection on type name, type, date, depth, mounts, properties, file system type, ownership, relative age, inode, symbolic link. find actions include delete, exec, print, quit. This can pass on needed information to further pipeline commands.

However, an interactive shell is meant to allow expression of commands with a reasonable minimum of keyboarding (thus ls and not dir). I could argue that the "Unix" command should be

find . -n ".docx"

(because the most common -n... option used is -name).

I think, to be fully reasonable the find command you want is

find . -regex ".*\.docx$"

which is still shorter than the PS example. I am not sure that for most interactive tasks, PS is a win. It does appear to be more elegant, but only usage over time will show if it is indeed more productive. I am looking for academic productive studies to be done, now that both bash and PS are available on common platforms.

If you're just talking about ls/dir, then PowerShell isn't really a win. The advantages are clearer when you start talking about lots and lots of commands. A lot (but not all!) Unix tools have flags to control their output format or input filters, but that means you have to memorize different flags for all of them. OTOH, in PS you just pipe to where/sort/select and they work for everything. IMO PowerShell has better separation of concerns.

In Powershell you can also do this:

  ls -Recurse -Include *.docx

or even this:

  ls -Recurse *.docx

which is really quite similar your find command.

I should have made it clear that this wasn't an example of Powershell being superior to bash, just what I can remember from that little script.

I've been hoping for a fully-featured Linux version of Powershell for a while, very awesome. I've used various Linux distributions for a long time and find bash very practical usually, but when I started learning Powershell when working in Windows environments I've been impressed with how easy it was to do some powerful stuff, and felt conflicted since I wanted to be able to use similar functionality and scripts across Linux/Windows.

Powershell isn't competing with bash, it's competing with Python. So then, how does it compare against Python? While plenty of small scripts are still done with bash, I think Python is pretty common for serious production needs. I use it for virtually all scripting these days.

I had a recent experience where a developer spent a day and couldn't get Powershell's webrequest library to do what he wanted. I was able to accomplish the goal in 15 minutes with Python on a Debian system.

Sure, there are different ways to do various things, especially depending on what one is familiar with and what the task at hand is. It sounds more like you knew how to get something done with your tools faster than the other guy/gal in this case. :)

Powershell really became interesting for me recently. I was working on diagnosing a production issue where one of our win32 applications failed on loading a .net assembly (dll). The error messages weren't terribly useful, and I wasn't getting a good stack trace. While Googling around, I found out that you can randomly instantiate .net objects from the PS command line. A few commands later and I had a full stack trace indicating the problem.

It's been such a difficult road. The consistency that PowerShell provides makes discovering things simple. There's no referencing a MAN page to see which parameter switch it is for _this_ tool. Yet, there's been no power. No ability to harness OSS tools in that way. Now, maybe I can have both.

"If Microsoft ever does applications for Linux it means I've won." - Linus Torvalds

For Fedora 24 users:

So some reason, the rpm that Microsoft provides doesn't list all the dependencies that it actually requires. What is even worse, the compiled binaries inside, require quite outdated versions of icu & openssl that are not available in Fedora 24 any more.

What I've come up w/ to force poweshell to run:

  # dnf install icu lldb lldb-devel lttng-tools lttng-ust

To view what we're still missing:

  $ find /opt/microsoft/powershell -name \*.so -type f | xargs ldd 2>/dev/null | grep not\ found
	    libcrypto.so.1.0.0 => not found
	    libicuuc.so.50 => not found
	    libicui18n.so.50 => not found

(libcypto* is openssl-libs package, libicu* is libicu.)

Now, you need to manually download:

http://archives.fedoraproject.org/pub/archive/fedora/linux/r...

(Yes, it's Fedora 17 == 2012 (!), which is ridiculous.)

http://archives.fedoraproject.org/pub/archive/fedora/linux/r...

and extract usr/lib64/* files from both rpms to, say, /opt/tmp/lib64.

Then finally run:

  $ LD_LIBRARY_PATH=/opt/tmp/lib64 powershell
  PowerShell
  Copyright (C) 2016 Microsoft Corporation. All rights reserved.

  PS /home/hf> $PSVersionTable

  Name                           Value
  ----                           -----
  PSVersion                      6.0.0-alpha
  PSEdition                      Core
  PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
  BuildVersion                   3.0.0.0
  GitCommitId                    v6.0.0-alpha.9
  CLRVersion
  WSManStackVersion              3.0
  PSRemotingProtocolVersion      2.3
  SerializationVersion           1.1.0.1

The build scripts for PowerShell right now require an existing powershell binary to work. If I can untangle this and work out what's required to build from scratch, then that'll probably help you build a proper Fedora RPM.

(I'm looking into it for Debian, but the work will help other distros, too).

Thank you for taking the time to share all that work you did to get Powershell running. Your instructions work for Fedora 23 as well.

I've been working on this for some time now, and am ecstatic to share this project with the world!

That is awesome. Truly an inspired set of changes at Microsoft lately.

Indeed

https://news.ycombinator.com/item?id=12305598

If people could be relied upon to maintain their own systems and apply security and other updates, this wouldn't be a problem. The unfortunate reality, is that they can't.

PowerShell is an improvement on Bash, but I'll still be using F# .fsx files for my .NET scripting needs. That said, the real reason I'm excited about this release is that there's finally a great example of a very large project based on .NET Core [1]! Most other examples I'd seen were pretty small, so this is really helpful.

[1] https://github.com/PowerShell/PowerShell

Can you share advantages or powershell improvements over Bash ? or is it kind of over-statement?

PowerShell is one of Microsoft's better offerings, it runs rings around Batch, thank heaven. However, it has its own quirks. Loads and loads of stuff done implicitly (unwrapping arrays as parameters when constructing an object?) and the .Net integration can be annoyingly flaky. Add in the bizarre syntax, some kind of halfway house between Bash and C#, and you quickly end up writing enough code to hang yourself.

My favourite: defining functions more or less like any other C-inspired language: function abc([string]$param1, [string]$param2) { #do stuff }

...but if you CALL that like any other C-inspired language: abc("string1", "string2)

PowerShell mashes the two strings together and ignores the second parameter. Drove me mad when I started out. Incredibly inconsistent.

I like Microsoft's effort here, and the design is a lot better, working with objects, but not on my Devuan box!!

You can run PowerShell Core inside of a Docker container quite easily as well.

https://channel9.msdn.com/Shows/msftazure/Run-PowerShell-Nat...

I'm something of an OO zealot and I'm a C# developer so I'm familiar with PS and probably it's target audience so to speak.

PS is a fantastic product but I just find it too verbose. When everything is expressed as an object with properties you need to reference the object and the appropriate property. I know there are alias' for common Bash operations and idiomatic PSallows shortcuts but most people who use PS for short spells to automate something are unlikely to be adopting idiomatic styles.

For PS to gain traction I feel like it needs to be a superset of Bash and offer an easier, intuitive gateway. I know it has enormous potential, I know it has massive capabilities but still I only reach for it as a last resort. I don't think I'm alone in the matter :/

I like Microsoft's move here. They first made available bash on Windows and then PowerShell on Linux. So no one is going to cry. And now they will improve PowerShell and win over users with a good tool rather than just because that's the only one available.

Powershell is an old tech, so browsing the source tree on github should show some of MS internal practices & guidelines in the old times. Yet the github project start in feb 2015. Where is the source code before that ?

On some interal MS RCS.

But why? It's like if VW invents doors that can be connected to BMW cars. (spoiler: BMW cars already have doors)

I don't understand Microsoft any more. They are making all their proprietary lock-in stuff open source, and they are alienating their user base. I've heard a number of long-term Microsoft users express frustration the user experience (not to mention the Windows 10 upgrade shenanigans). It was bad enough that my dad, a long-time lover of Windows NT (he liked its VMS legacy) switched to a Mac and loves it.

I feel like Microsoft might be pulling a Sun here. However, I'm sure a lot more likely to use Microsoft stuff if I'm not tied in to Windows.

As a counterpoint, I've been a full-time Linux user (desktop and server) for well over 10 years, with server use for 20. (I'm 40, so while others have used Linux/unix longer than me, this is the entirety of my adult working life.)

With the open-sourced .NET stuff, I've been active in pushing for projects I touch to use it. And, I now dual-boot Windows 10 and Linux, actually using Windows for daily work for the first time in a decade.

Open source C#? Sign me up. And I really do like the Windows 10 interface. The telemetry stuff just doesn't bother me. I think it's largely a red herring.

(And, furthermore, I think privacy stuff really has to get nailed down in laws and society, not just with technology. Going just for a technical solution means you'll always be chasing the answer. Encoding it in laws, and setting people's societal expectations, means you get to set the answer instead of follow behind.)

The main fallacy is to think someone can 'understand' any big corp. Especially Microsoft - http://www.bonkersworld.net/organizational-charts/

they just try to get some developers back on board. Did not sork out so well so far i guess.

Finally! It's exactly what we need since there are currently no scripting languages available in Unix user-land for when you need to do something beyond /bin/bash

Poe's law

The initial release is an “alpha” and is community supported. In the future, we will deliver an official Microsoft released version of PowerShell based on open source to anyone running a supported version of Windows or nix. The timing of the official Microsoft version will be based upon community input and business needs. We hope all of you will help us get it right!

'Based on business needs' = if there's ever enough demand.

Still, pretty cool.

Windows can have a neat-o shell all they want but when you open powershell on a windows computer you still get the following when you try to ssh... so, not really seeing the point here:

ssh : The term 'ssh' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

see: https://github.com/PowerShell/Win32-OpenSSH. ssh is coming, likely in an official capacity in the future (this is an official MS group on github)

Having lived around the Windows world since Win 3.1, I cannot get over the sneaking suspicion that somewhere deep down Microsoft is working towards an attempt to "embrace and extend" Linux. Maybe it's just me, but they've gotten rather interested in Linux lately and they are reaching out to it in seemly innocuous ways. I hope I am wrong.

I just spent all day trying to figure out why Invoke-SqlCmd only works in certain extremely convoluted ways. I'm going to assume this has more to do with the Sql Server team than it does to do with the powershell team, but still: I cannot be excited about anything to do with Powershell since I'm now up to like 10 Googles per line.

Strongly-typed scripting is nice, but I think PowerShell has horrid syntax. I would rather take .fsx scripts any day.

(.fsx scripts are F#, so also strongly typed)

I think PS is miles above CMD but there are still things that bug me. For one, loading scripts into the current session is super confusing to me. Sometimes they are automatically available, other times I have to load them, still others aren't available at all. I'm guessing there is some way to "install" scripts so that they become cmdlets but I don't know what it is.

Another big problem I've had is backgrounding commands. There are multiple ways to do it and I always seem to pick the wrong one. For example, I want to install a bunch of things with Chocolate so I do a lot of Start-Process commands, but they seem to run serially and not in parallel. It's just very difficult to manage jobs in PS, or at least I haven't found any good information on how to do it properly.

OK, so you can finally fix the bug that breaks non-ASCII, LF line endings and binary redirection. Link: https://github.com/PowerShell/PowerShell/issues/1908

A lot of people seem to be missing the point of PowerShell. The concept is far more poweful than the unix shells, because it's a superset of them. It's like Haskell and Haskell-without-types.

We could only dream we had something like strongly-typed pipes in Unix -- and that various tools supported it too.

It's amazing what happens when a company starts to lose market share, isn't it?

I've got this embarrassingly ugly perl-inside-cygwin to automate something with a GUI tool that happens to have an even worse scripting plugin.

I suspect Powershell would allow me to take the whole process native?

I dreaded this day would come. As a recent ex-Microsoft alumnus, and with years of System Center insanity behind my back, I saw this coming, and even heard faint echoes of it in the hallways as I left.

I have deep respect for Jeffrey and what he's accomplished (there's a great video of Jeffrey talking to Linux sysadmins and explaining the genesis of PowerShell, including the insane amount of money we burned before he wrote the bits that actually worked over Christmas break), but the grand (corporate) motivation for sponsoring something like this is more driven towards making sure the MS datacenter management tooling (which comprises trendy things like OMS and System Center) attain minimal mindshare in both the on-premises datacenter and on Azure.

That is not something most people would care about, but Enterprise IT likes having a single hammer for all its nails, and PowerShell's promise is to be the one thing that your garden variety IT sysadmin would love to use to automate every single system in your company.

Ironically, PS is effectively lousy at automation because of its inconsistent error handling and incredibly hard to maintain over time due to constant changes and updates, so I'm curious to see how it will evolve to manage all the different abstractions in the UNIX world (knowing my former colleagues, it will likely follow the OMS route of "Windowzifying" those abstractions and making them "uniform" - i.e., Windows-like).

The underlying issue where it regards PowerShell is not the language itself (although yes, something better, more coherent and with an actual standard library would have been nice, like Ruby or Python). It's Windows.

Windows (the enterprise platform) has always been a hectic patchwork of multiple components (AD, SQL, IIS, etc.) that evolve at their own pace, and PowerShell grew to encompass them not merely because basic automation was an actual checkbox we had to have to be able to sign some hefty deals, but, technically because _none of it had open APIs_. Nor would it be feasible at the time to go back and re-do any of it with proper language-agnostic APIs.

It's very nice to iterate over AD entries and set some fields with a couple of lines of PowerShell, yes. But it's also fundamentally impossible to do so with just about anything else.

Tying it all to the .NET stack (which is still prevalent in everything done internally, because that's what customers invested in) turned out to be a lazy-ass way to ensure we could check all the boxes in terms of automating new things as they came along (mostly - WMI is still iffy). Effective and "scriptable", but essentially still proprietary.

And right now, since my former colleagues are betting the farm on Azure, I expect PS for Linux to become the de facto scripting language for managing Linux on it (it already is, to a degree, since PowerShell DSC already lets you "manage" Linux VMs).

For interactive use, PS was a pain to learn (I was a VMS guy, originally), but, most importantly, it was a nightmare to maintain, because cmdlets would pop up and disappear between releases, change semantics, and were quite often inconsistent among themselves.

I shudder at the level of technical debt would-be adopters will be buying into, and wish them luck.

mod parent up!

(sorry, all this MS vs. Linux discussion brought me back to the slashdot days)

Seriously, powershell finally makes sense to me after reading this. Thank you.

I am pretty excited about this as I have few cross-platform languages that I can use (due to conditions at work). I am wondering how many distros will adopt it into their repos.

Probably most distos that want to be available on azure. Which is why this happened really.

I fully expect this to be in the AUR in under a week. Probably within 48 hours, even.

...and it's already in the AUR. It doesn't run yet, though.

Get-CobolFingers -Variant=Microsoft -Payoff=MuchLessThanAdvertised

    Get-Cob{tab}{tab} -v{tab} M{tab} -P{tab}{tab} M{tab}

cmdlet long parameter names both a) work if you type "the shortest non-clashing prefix", and b) tab complete. And if a parameter takes an enumeration you can tab complete those, too. Which is incredibly nicer than usage: somecmd -umhcglsrfmh line noise and man page lookups.

Actually, you can ctrl+space in latest versions to get a list of parameters (or values if the parameter takes an enumeration) you can scroll around with the arrow keys :)

It's better than reading regex linenoise.

Is there anything preventing Microsoft from putting a Linux shell natively on Windows? I'm sure PowerShell is awesome, but the DevOps person in me is not excited at all.

Not quite what you're looking for, but arguably better: https://msdn.microsoft.com/en-us/commandline/wsl/about

Been playing with it ever since I got a new Windows laptop for college (I usually would have installed Debian but I prefer OneNote to notetaking apps on available on Linux). The interesting part is that it's not a VM; the LoW subsystem translates Linux syscalls to Win32 ones

this x100. i wish they'd work on chef/puppet/ansible/salt support instead. probably never going to happen though, so much functionality in windows isn't available from the command line.

Yeah, probably never happen. You'd never see J. Snover the 'father of PowerShell' at ChefConf last year talking about PowerShell Desired State Configuration (DSC) and its support for Chef (https://www.youtube.com/watch?v=Gh9zfm5gVEg) or two years ago the PowerShell team announcing a DSC Cookbook for Chef (https://blogs.msdn.microsoft.com/powershell/2014/07/29/chef-...) or last year announcing Puppet's announcement of support for PowerShell DSC ( https://blogs.msdn.microsoft.com/powershell/2015/10/06/desir... )

You know that the entire point of PowerShell is to make Windows functionality available from the command line, for centralised management and configuration, for automated provisioning on Azure, right?

That is how we got started on this. We didn't want to invent anything here. We had a technology called Services for Unix which provided all the shells and utils and I got 99.5% of the way to getting that shipped natively in Windows but it got hung up over IP concerns. So we made it free instead.

It turns out it didn't help managing Windows at all.

The heart of the problem is that Unix is a Document-oriented OS and Windows is an API-oriented OS. In Unix, if you can edit a file and restart a process - you can do most management tasks. Therefore text processing utils like awk, sed, grep are actually management tools. When these became available on Windows - they didn't help manage anything because awk didn't work against the registry, sed didn't work against WMI, grep didn't work against Active Directory. An API-oriented OS needed an API-oriented solution.

That is why we HAD to invent PowerShell. I believed that the Unix automation model was fundamentally correct: Interactive shell composing small tools together in ad hoc ways to quickly construct novel solutions to novel problems. I like to call this the " A | B | C" model.

I did a deep rethink of the "A | B | C" model and asked myself the question WHY? Why not just type A? Why didn't A do what I wanted it to do?

There is the traditional answer about toolchest of tiny tools but I keep chewing on it and came up with a different answer:

  A tightly binds 3 steps into 1.  It

   1) Gets a set of objects

   2) Processes those objects

   3) Outputs those objects (typically as text)

When when we say A doesn't do what I want it to do, what I'm REALLY saying is that A did one of those 3 steps in a way I didn't want. So piping the results to B and C is REALLY all about taking the text and reverse engineering my way back to the original objects to do one of the steps differently.

My observation was that the pipeline should go between the 3 (smaller) steps and that the pipeline should pass objects and only output to text when you wanted text.

This object orientation is one of the great simplifies of PowerShell. It allows us to shift our focus from the mechanics of text parsing to the semantics of what I want to achieve. We like to call this THINK, TYPE, GET.

THINK about what you want.

Type it

Get it

Imagine you wanted to get all the processes whose workingset was greater than 5mb and sort it by workingset and then format that as a table just showing the name the id and the workingset - in PowerShell, you would do that with this:

PS> Get-Process | Where workingset -ge 5mb |sort workingset | format-table name,id,workingset

some people complain about the verbosity of PowerShell but that is there for scripts. We have lots of aliases for interactive use. Here is an equiv:

PS> gps|? workingset -ge 5mb|sort workingset|ft name,id,workingset

So that is the answer - a lot of the great Unix tools don't work on Windows because it is an API-oriented OS. So we had to develop an API-oriented automation model - that is PowerShell.

Jeffrey Snover [MSFT]

In the fifth paragraph: "But this is a new Microsoft". They are acknowledging that they made mistakes in the past due to which the missed out big on the server market. As much as .NET is popular, it would have been a lot more popular (vs Java ecosystem) if they were OSS from the beginning. As primarily a Java developer, C# seems more elegant to code in.

As they say - the first step to fixing a problem is admitting that you have a problem.

the Unix shell has been quite static in recent decades; its a sign of success, sharing unstructured text through a pipe is good enough for most administration tasks and people got used to the many command line options of grep/sed/ps and friends.

is this really the best of all possible worlds? I think that its good that the shells get some new competition in the form of PowerShell - maybe some new ideas will come out of it (maybe like passing s-expressions or json around the pipe - something more structured so that we could do with fewer command line options - maybe)

doing structured data 'right' is difficult (right meaning uniform and expressive ways of handling it); historically it was easier to stick with unstructured text - but maybe there is a better way that would be easier to learn and handle.

(Well a major problem of structured data is that there are many possible ways of structuring - leading to more problems for the consumer of the data; maybe it was not adopted in system administration because there is not common/agreed upon culture of how to structure things).

Excellent news. Now I might actually learn PowerShell

Its not clear to me what this means to Powershell SDK? (https://technet.microsoft.com/en-us/library/ff458115.aspx). Will I be able to write applications (not scripts) in say C++ to communicate to say SCVMM?

Great. I wonder what Steve Ballmer is thinking.

Ballmer's long gone, so he's probably thinking about the LA Clippers (he's the owner).

Probably "<something>, <something>, developers".

I'd love to know his reaction to and thoughts surrounding this move.

he's thinking about an nba championship.

Steve who?

He gets his share of evilness with Windows 10 wreaking havoc in users' privacy. Microsoft doesn't seem to have changed that much.

Still need something other than powershell to access a linux server from a windows machine, which seems ironic...

What would a shell have to do with the existence of a userland program? ssh isn't exactly a bash built-in either ...

An (unofficial) PowerShell AppImage is now available for anyone interested in trying out PowerShell. No installation necessary. https://bintray.com/probono/AppImages/PowerShell#files

  milek7: ~$ time powershell exit
  
  real	0m3.323s
  user	0m4.140s
  sys	0m0.507s

Seriously?

Propably bit unfair comprasion, but...:

  milek7: ~$ time bash -c exit
  
  real	0m0.009s
  user	0m0.007s
  sys	0m0.000s

Can I write tools that use PowerShell and .NET objects in non-.NET languages, like Python or Perl (using the C implementations, not a .net python)? Like, is there an API that I can implement to interact to implement PowerShell-like "native" tools?

It's not the most efficient way to do it, but if you just want to get it done, Powershell has had e.g. ConvertTo-Json since version 3, I think? You can serialize pretty much anything at that point, and just hand that off to your target language.

If you're talking an FFI though, not so much, I think.

use pythonnet to interact with .NET dlls from CPython:

https://github.com/pythonnet/pythonnet

On the Java side here I tend to use groovyConsole when I need to do crazy one off stuff like open excel files which then require a DB query, and maybe to run regexs for little things. I use bash for running docker commands in a specific sequence.

I made a Docker container running PowerShell on CentOS7: http://github.com/gbraad/docker-mono Have fun with it...

Coming soon to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834756.

If PowerShell on Linux takes off properly, then that will lead to one of the biggest improvements in the general computing ecosystem in a long time; roughly comparable to the adoption of DVCS, maybe.

`cat youCantBeWorseThanCmdRight.utf8.txt > openMeAfter.txt` in PowerShell and cmd, and tell me how good posh is

now go tail a 1GB file in posh and bash and tell us your results

PowerShell defaults to UTF-16 encoding, indeed. It's a design choice on a system that uses UTF-16LE as its character encoding and one from the early 2000s. UTF-8 wasn't nearly as prevalent back then. However, the text in both files is still the same.

    Get-Content -Tail some1gbfile.txt

works quite well, by the way.

well, enjoy typing

    Get-Content -Encoding utf8 .\utf8.txt | Out-File -Encoding utf8 out.txt

and manually removing the BOM, for the rest of your life

Parsing text is unfortunately not one posh's strenghts... but one of the beauties of posh is that you can very easily include .NET classes, so you could e.g. use the System.IO.StreamReader class https://rkeithhill.wordpress.com/2008/03/02/nothings-perfect...

On the other hand, with posh I could ingest a json file and convert it into an object (or an array of) with ConvertTo-JSON. Once I've got the object, I can query/navigate it instead of parsing it. I'm not sure it is that easy with bash, but then again they are not mutually exclusive, so it's great to have both now on Linux and on Windows.

I am still trying to understand if there are any tangible benefits on learning powershell over bash/zsh.

I wouldn't think of it as a replacement for bash/zsh or other shells. Those are meant to control the OS and run programs where powershell is an environment to programatically interact with API's. They can both fill similar roles but their not the same.

Piggybacking on this thread, I wonder if there's a robust PowerShell profiler out there.

I bought a new laptop recently, and used Windows for a little while (I didn't have time or a USB drive handy for installing Linux for a couple of weeks). I was pleasantly surprised at PowerShell. Not because of all the stuff people normally like about PowerShell; all the PS things are still confusing as hell, to me. But, because MS has embraced compromise and meeting developers where they are in ways that I have never seen from MS until recently.

PowerShell now accepts most of the common UNIX shell commands (this feature could have come at any point in the past decade, or so, as that's how long it has been since I last tried PowerShell, when it was new). The changes that resulted from that change of mindset has made it so I could actually stay in PowerShell long enough to learn other things. Having to re-train my muscle memory away from using stuff like ls, cp, cd, was just a bridge too far, and so in the past I'd revert to cmd (as truly awful as it is) until I could get bash installed from Cygwin.

They seem to have, somewhere along the way (again, it may have been a decade ago, for all I know) given PowerShell a reasonable UNIX shell facade. Sure, it's not quite shell, but bash/POSIX shell isn't flawless; I'm OK with changes, as long as I don't have to think every time I want to do basic stuff that I've been doing for 20+ years with a POSIX or bash shell. PowerShell has some Long-Ass-Command-Names, and I still find them difficult to stomach, but at least all the common sh equivalents (except which, for some reason) already have aliases.

Anyway, the change from a company that tells developers how to work (and for whom the command line takes a back seat to GUI tools and most developers live in the Visual Studio environment, I guess) to one that looks at what's working in all sorts of developer communities and borrows liberally from the best of them, means that having to work on Windows is no longer the worst possible thing I can imagine (I'm even considering porting our products to Windows, which is a suggestiong I have laughed at numerous times over the years).

PowerShell, as it is today, reflects that change, and open sourcing so much stuff lately seems to prove it is sincere rather than merely aping the most visible traits of these OSS communities without actually embracing the single most important facet of them.

I still have an old OSS nerds suspicion of Microsoft, and I will probably never choose Windows as my favorite desktop OS (and I can't even imagine it for server usage...how would you even do that without a decent system package manager?), but my most recent experience with Windows was almost entirely positive. Interoperability has gotten pretty good. SSH is a normal thing, rather than a complicated setup process.

It's interesting, to me, that Apple seems to have been retreating on these fronts. They seem to be less interested in participating in OSS than they were in the early days of Mac OS X. That may be my own ignorance of the platform, but I don't see Apple making these kinds of overtures to Linux/UNIX developers on such a regular basis. Maybe they figure the community is taking care of it for them, because so many devs use Apple laptops even while deploying to Linux servers, so the ecosystem is still pretty strong even without Apple doing much of the work.

"and I can't even imagine it for server usage...how would you even do that without a decent system package manager?"

I'd be pretty hesitant myself to use it as a web-facing server. But if you're running an enterprise network, the reality is almost everything you need on your server can be added and removed from the "Add Roles and Features" wizard. There's not a whole ton of outside packages you would want to add.

If your server is running third party software, you should probably only run that one piece of software on that particular server, and that software should install everything it needs to run on it's own.

Powershell released in 2016 still isnt as powerful as Stephen R. Bourne's shell released in 1971.

Is this actually useful?

I always thought powershell was largely just for interacting with windows components, like installing an msi or talking to active directory.

What would you actually practically use this for on a linux box?

The ramp-up period is much lower with Powershell.

It is truly an interactive ("online") environment. Almost everything is typed and through introspection the shell can offer very rich auto-completion hints, without needing tedious scripts such as those used by bash/zsh.

Quick example:

get-<Tab> cycles through all get-[whatever] commands, as you'd expect. get-certificate <Tab> cycles through all parameters available for get-certificate get-certificate -ErrorAction <Tab> cycles through the list of valid values for ErrorAction (there's like 6 of them: stop, suspend, etc.)

It is also highly standardized, there's a set of "verbs" allowed so that it's much easier to find something since everything is in a certain category (https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).a...)

It has its bad/ugly bits, but the principles are quite solid. In many ways they are what I'd expect if Richie and Thompson would have designed Unix in a modern environment (i.e. not an environment where the output of your commands would be printed :) ).

Scripting. While I typically use Bash on Windows to use grep to interactively test my webserver, I'm much happier using Powershell ISE (which I don't know was ported [1]) to write standard tests with multiple parts, particularly ones that require e.g. checking cookies on the response.

1. Looks like they ported a service that does the same. https://github.com/powershell/powershelleditorservices

symbolic soft link yet?

People laugh at me when I tell them I switched "back" to Windows after decades of Unix and Mac programming. But it's a really good, productive platform. Microsoft really seems to be heading in the right direction now.

I hope .NET starts taking off on other platforms, too, because it really is a much better system than Brand "J".

If only they resolve the privacy leakage concerns in a reasonable manner.

Amen. Having used Windows Server and various Unixes, I much prefer Windows.

If you meant Java, say Java please. Brand "J"? To me, that would mean J/K/APL/APL2 (MATLAB, Nial, S, R, and other array systems). But I guess Brand "J" is cute.

I don't want to be that smug ITT guy but it has to be said:

Bash != Readline and Bash != coreutils and Bash != (what gives your machine the ability to do ssh)

Bash is the stupid if for while syntax

You have Readline in powershell and you can use coreutils binaries in Powershell. No problems there.

Powershell is a horrible abortion, what the hell do people see in it? I mean that on a language level, I cant speak for Windows specific features. I have once written a simple script to copy a folder recursively to a fileshare, rename some stuff, edit some files. Took me 4-5 hours. I then did it with julia in 30 minutes and I never did anything in either language before that. It's insane the kind of weird language crap you have to deal with, the weird options that some functions need and worst of all: That the functions have weird problems, like I dont remember the specifics but I'm pretty sure that the folder copy function had no option to actually recursively copy all of them. I had to work around that. Then I had to work around some more specifics around file/folders. In a normal language you would just call something like "copyFolder(srcPath, dstPath, recursive: true)" nope.

I wouldn't go so far as to call it a "horrible abortion" - but it can be painful to use at times. I manage several Azure environments with PowerShell and not a day goes by that I don't wish there was something better. Especially on those days when I have to dig into Azure's JSON templates.

There is an SDK for Python, but I haven't had an opportunity to try it. If anyone has used it I would love to hear about your experience.

oh man I agree with you so much. You can't do anything data intensive with powershell, it is too slow.

This might come across as a little rude, but I really wish Windows developers stayed away from Unix. I moved away from Windows a long time ago because I didn't want anything to do with Windows or Microsoft, and I went to great lengths to avoid their software and their proprietary file formats. Now we had command-line interfaces, desktop environments, running on top of an incredible, powerful Unix-like OS. It was free software, and it was Microsoft-free. Please, don't ruin it.

"Um excuse me, but I really like dogs. However, I don't like you, so I don't want you making movies about dogs. Dogs are my thing. Stay away from the concept of dogs."

I have to agree. I can only feel like this is pollution or another EEE attempt.

Cool. https://powershell.org/ needs some work though. It screams WordPress 2008 website, and I'm not given any idea how to install or use it, or what it's good for, just by looking at the front page.

It is not a Microsoft website.

https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

This could really be used as the default reply for a lot comments here that don't get why people are still a bit antsy about MS apparently doing things for the good of others besides MS. But it's probably an argument only worth having in one thread. I can't really add much to the argument, other than I think my feeling matches a lot of others in the OSS world: ever since Nadella took the helm I've been cautiously optimistic that we're not just part of a very long embrace+extend cycle that will end with a crushing extinguish, additionally as the years go by without an attempt at extinguishing but even more embracing+extending instead, with MS having lost so much of its former power and weight in the industry as a whole, I think even an extinguish attempt wouldn't be all that successful. It's not enough for me to actually use these offerings, but I'm not going to go on a rant that no one should use them or distros should avoid packaging them. (e.g. Stallman once had a Mono+Banshee rant that was probably justified at the time but it's hard to argue the position now.)

Reply on news.ycombinator.com