
Microsoft’s PowerShell Core Offers Cross-Platform Automation - el_duderino
https://thenewstack.io/cross-platform-open-source-powershell-goes-net-core-runs/
======
mpweiher
Conceptually, Powershell is really cool.

But in practice, I find it both cumbersome and very, very slow.

For example:

    
    
       marcel@vger[Downloads]time pwsh -c 'ls' >/dev/null 
    
       real	0m0.824s
       user	0m0.636s
       sys	0m0.213s
       marcel@vger[Downloads]time sh -c 'ls' >/dev/null 
    
       real	0m0.011s
       user	0m0.003s
       sys	0m0.005s
       marcel@vger[Downloads]
       

That's around a factor 80. Hmm. OK, startup costs, JITs hard time, yadda
yadda.

But it's not just that. For example I found a simple

    
    
        dir -r
    

to be more around 50x slower than the equivalent

    
    
         ls -lR
    

And so on.

~~~
SwellJoe
On top of this, writing PowerShell feels like _programming_ rather than
_scripting_. I know that's sort of ambiguous, but PowerShell is astonishingly
verbose compared to bash, or sed/awk, or Perl. PowerShell may be a better
programming language than bash, but the times I wrote some, it took me a lot
longer (maybe mostly because of my own familiarity with bash) and the
resulting scripts were bigger (which I think is unavoidable).

I just don't find PowerShell fills a niche I need to fill, even though it
seems to be really powerful and designed by smart people. I guess if I worked
on Windows it would fill a niche since it has hooks into the system that are
harder to reach in other non-MS languages.

~~~
wvenable
My biggest complaint with PowerShell is that it's unnecessarily inscrutable --
filled with Bash-like and Perl-like syntax and semantics without the legacy to
justify it. I wish writing in PowerShell was as easy as writing C# but instead
it's almost as bad as writing Bash scripts.

It's not good for programming or scripting. There are so many good ideas in
PowerShell but it's wrapped in a weird body.

~~~
darksim905
As a Syasdmin, Powershell is a scripting dream: it has tab completion for the
commands _and_ the switches. I don't feel like I have to guess or look at man
pages to figure out why there's a -s and an -S. The help pages are usually
written for human consumption by comparison. Saying that it is 'unnecessarily
inscrutable' is quite hilarious - have you seen some Linux commands & the lack
of output they give? Powershell, if anything, ins extremely verbose & is clear
in when something goes wrong.

At least, it doesn't insult you like Ansible tooling with the ^ YOU MADE A
MISTAKE HERE BUT WE CAN'T BE CLEAR WHAT IT IS

~~~
mattmanser
We have all of that in C# without the rediculously bad syntax.

It's such a shame powershell didn't come 2 years later, I feel like they'd
have had no choice but to use C# instead of inventing a new language.

~~~
JeffreySnover
We thought about that but the reality is that it does not work well for
interactive experiences.

When you look at how admins get their job done, it starts in the interactive
shell and then when the do things frequently, they put it into a simple script
and when then need it to be more formal, they invest in making it production
quality.

That is the flow that PowerShell was designed to support.

Jeffrey Snover [MSFT]

~~~
figgis
Could you just allow interaction with objects in a shell while just using c#?
There are interactive c# interpreters that already do great.

------
antoncohen
PowerShell is kind of bizarre. I totally get why is has taken off with Windows
sysadmins, compared to the previous built-in alternatives it is _amazing_.

I think a lot of the bizarreness comes from trying to be multiple things, an
interactive shell and systems automation language. It is case-insensitive,
with seemingly no consensus on what case to use for things. Kinda makes sense
for a shell environment with a case-insensitive file system, but very odd when
writing automation. It can be written to look like any modern C-like language;
set variables, pass variables to functions, etc. But idiomatic PowerShell
seems to be (at least in some circles) piping one function to the next in
_very_ long chains. Again, that makes sense in a shell, but becomes somewhat
unreadable in an application.

Most of what I've seen PowerShell used for is automation, from small 1000 line
scripts to seriously large applications with libraries and databases. And I
can't help but think that Python would have been so much nicer, if only it was
built-in to Windows. Python has libraries for working with the Win32 API and
COM objects, there is even IronPython which runs on the CRL and can integrate
with .NET.

I don't think anyone was asking for an interactive shell and a serious
programming language to be combined, and it would have been nice if they were
separate. Instead they have an awful terminal console, an oddly verbose shell
language, and a slow case-insensitive programming language.

~~~
ZenoArrow
> "It is case-insensitive, with seemingly no consensus on what case to use for
> things."

There are naming conventions in PowerShell, but you don't need to know about
them when you start out. For example, it's common practice to use camel case
for variable names, such as $myVariableName.

> "But idiomatic PowerShell seems to be (at least in some circles) piping one
> function to the next in very long chains."

For the code I've seen and written, it's rare to see pipes longer than 4
commands long. If you get any longer than that, it's easy to store the output
object in a variable and continue to work with this variable as a shorthand.

~~~
antoncohen
Regarding case-insensitivity, I'm not referring to user picked names, I'm
referring to the whole language.

Is it ForEach, Foreach, foreach, or ForEach-Object? Official
documentation[1][2][3][4][5] has all four variations. Same for True/False,
While, Write-Output, etc. Everything is case-insensitive and the docs can't
decide which to use. Again, it kind of makes sense for a shell language when
your users are used to case-insensitivity, but I much prefer stricter
consistency in programming languages.

[1] [https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.core/about/about_foreach?view=powershell-5.1)

[2] [https://docs.microsoft.com/en-
us/powershell/module/psworkflo...](https://docs.microsoft.com/en-
us/powershell/module/psworkflow/about/about_foreach-
parallel?view=powershell-5.1)

[3] [https://docs.microsoft.com/en-us/previous-
versions/windows/i...](https://docs.microsoft.com/en-us/previous-
versions/windows/it-pro/windows-powershell-1.0/ee176828\(v=technet.10\))

[4] [https://technet.microsoft.com/en-
us/library/hh551144.aspx](https://technet.microsoft.com/en-
us/library/hh551144.aspx)

[5] [https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.core/foreach-
object?view=powershell-5.1)

~~~
ZenoArrow
ForEach is an unusual statement. Depending on the context in which it's used,
sometimes it's an alias of ForEach-Object, but sometimes it is not. The
following article has more details on this, but one thing that I'd like to
highlight now is that one way that ForEach and ForEach-Object can differ from
each other is in memory use, as ForEach will load all objects that it's
iterating over into memory first before starting the loop, whereas ForEach-
Object will not. As suggested before, more details can be found here:

[https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/...](https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/08/getting-
to-know-foreach-and-foreach-object/)

Going back to the naming conventions, the conventional way to write ForEach is
in PascalCase. The variations slip into code as it's also an alias, and
aliases tend to be in all lower case, and also because naming convention
guidelines are just suggestions, not something that is strongly enforced
(Foreach does seem to be commonly used, even if it's not necessarily in the
standard styles).

Generally speaking, PowerShell coding style is similar to .NET coding style.
You can read a discussion about it here:

[https://github.com/PoshCode/PowerShellPracticeAndStyle/issue...](https://github.com/PoshCode/PowerShellPracticeAndStyle/issues/36)

By the way, I respect your right to use whatever language you like best, I'm
just clarifying that whilst PowerShell may not have it's "PEP-8" or gofmt,
there are still conventions that PowerShell coders follow.

------
macromaniac
If PowerShell is bad because its too much like a programming language thats
fine with me. I like being able to hop onto any windows computer and make
things happen. I can scrape websites, consume web apis, host webservers, and
more all in beautiful one liners. Also text to speech and wscriptshell are fun
for messing with your friends computers.

------
InclinedPlane
Oh goodie, a PowerShell thread on HN. I'm excited to see how many variations
of "I hate PowerShell because I've never bothered to spend time learning how
to use it, so I don't, and it's also not X, which I use and like" will show
up.

------
cutler
So long as Microsoft continues to operate its Linux patent racket I won't be
letting PowerShell or .Net Core anywhere near my Linux boxen. People, wake-up.
It is NOT OK to let Microsoft become another Linux player without holding it
to account for its current and past anti-open source practices.

------
maxharris
From the bottom of the article: _Microsoft is a sponsor of The New Stack._

Please don't link to articles from The New Stack. Their articles are often
nothing more than warmed over press releases...

------
achy2
Personal opinion: I tend to find that the times when I end up using advanced
Powershell features, I should have been writing code; and times when I don't I
could easily have used a batch file.

It's too bad that the focus wasn't put on creating an amazing .net interpreter
for the commandline.

------
pitaj
If only it had `&&`

~~~
seabrookmx
100x yes. The amount of times per day I do something along the lines of

git add --all && git commend

(commend being an alias for "commit --amend --no-edit")

or

npm install && npm prune && npm run watch

This is the main reason I use git-bash as my primary terminal whenever I'm
working on Windows.

~~~
WorldMaker
Semicolon works, though doesn't have the quit/shortcutting on exit code
semantics.

There are some community tools to fake it a little better (Get-ExitBoolean).

Also, a big GitHub issue tracking it:
[https://github.com/PowerShell/PowerShell/issues/3241](https://github.com/PowerShell/PowerShell/issues/3241)

~~~
darrenf
> _Semicolon works, though doesn 't have the quit/shortcutting on exit code
> semantics._

I would say it's a little more than semantics. Consider

    
    
        cd /some/dir/with/a/typo && some_destructive_cmd .
    

vs the semi-colon equivalent.

~~~
WorldMaker
No, absolutely, there are many cases where semicolon is a bad replacement and
a more suitable arrangement found. I'm just speaking to a lot of the "quick
one line scripts" that aren't dangerous, such at the parent suggested. Things
like `npm install && npm prune` are fine as `npm install; npm prune`. It may
"waste" cycles in the rare case of a failed install, but it isn't dangerous.

I agree though, a good short-circuiting Boolean operator would be nice.

------
telltruth
PowerShell is fundamentally flawed system. The object oriented language does
not belong to shell. It’s simply too verbose and awkward for repeated fast
interactive use. When tons of commands starts with get-*, that’s 4 extra
keystrokes before even you begin to specify actual command. I know there are
shortcuts but still that’s workaround this bad foundation.

A general purpose programming language where you write statement and it stays
there and gets executed million times is very different model than shell
language where you write statement, throw it away and move on with next.
Combining both is creating Frankenstein that’s good at neither. It’s just
quite funny that PowerShell syntax doesn’t allow == but does need curlies. Who
in the world would have thought of that?

Also the view that everything in shell should output structured data is plain
wrong. Shell should output human readable formats. always. It’s tool’s job to
do proper parsing and deal with related complexity. The convenience should
always be afforded to humans, not tools. Even if one changes all built-in
commands to comply this, vast majority of programs won’t.

So lot of above leads to Frankenstein-ish design that looks like awkward hodge
pudge of bandaids. While cross platform is good, MSFT needs to start brand new
effort, leave PowerShell behind and take command line to next generation with
right first principles.

------
unsignedint
I've migrated some of bash scripts I use, so the same script can be used for
Windows and Linux.

Bash ports on Windows can be messy especially if it involves non-Latin
codepages, especially when it involves language like Japanese, which frontend
is still not migrated fully into UTF-8. (Also WSL handles it more gracefully.)

I am program in C# a lot, so extensibility via CmdLet is also interesting.
(Although, I haven't explored this much, yet...)

~~~
luch
You should : even if I consider Powershell pretty alien as a language (coming
from an old time Windows dev), Cmdlet is vastly superior to other various
argument parsing tooling (optparse, argparse, argv, etc.) I've used in the
past.

~~~
ZenoArrow
> "Cmdlet is vastly superior to other various argument parsing tooling
> (optparse, argparse, argv, etc.) I've used in the past."

I can't comment on the other options you listed, but I would agree that
PowerShell has good features for parsing arguments (if you use advanced
cmdlets, which only require one extra line to enable on basic cmdlet code, for
[CmdletBinding()] ). Aside from built-in attributes for enabling common
argument checks (like checking for nulls), you can completely customise
parameter validation using ValidateScript, which allows you to set up a script
that must evaluate as true in order for an argument to be valid. I'd be
interested to find out if any Unix command line scripting language offers
something similar.

------
rosege
As someone thats never been very good at programming in full languages I find
that PowerShell is very easy to learn and quite intuitive once you know the
basics. I have used it for a huge amount of things that are quite varied. I
dont think I've ever had a thought of something I wanted to accomplish and
wasnt able to do it (eventually in PowerShell)

------
beagle3
For those who don't like PowerShell's syntax and choices, I highly recommend
looking at [http://xon.sh/tutorial.html](http://xon.sh/tutorial.html) \- it's
a marriage of Python and a shell done right, and it's cross platform.

------
SloopJon
Criminy, the Mac tarball expands to over a hundred megabytes, with at least
two hundred DLLs and dylibs. If I already have .NET Core installed, is running
dotnet pwsh.dll basically the same as running pwsh?

------
jitl
You know what also offers cross-platform automation and has packages available
on all named operating systems?

Bash.

~~~
justinsaccount
> cross-platform automation

> bash

Nope. Show me the script that gets a list of mounted filesytems for locally
attached disks and flags any that are larger than 20G and are more than 90%
full.

Since it is cross platform it will run the same on linux/bsd/os x and windows,
right?

~~~
blacksmith_tb
I haven't used the Windows Subsystem for Linux much, but shouldn't it be
possible to have a bash script that runs on all of them? (though it might take
some testing against the environment, for things like osx's /Volumes etc.)

~~~
maxsilver
I use WSL daily, and yes you can see your entire C:\ drive in WSL under
/mnt/c/, and all the common directory commands work, so running a bash script
is 'cross-platform' in that way.

That's sort of cheating though. In that instance, Bash isn't really being
cross platform, so much as Windows bent over backwards to re-implement lots of
Linux underneath Bash, so Bash could treat Linux and Linux (on Windows)
identically.

Or to restate that: If Linux apps get to claim they are 'cross-platform'
because of WSL, then Windows apps get to claim they are 'cross-platform'
because you could run them in WINE.

------
cup-of-tea
I'm a bash guy. I'd heard of Powershell and thought it was interesting that
Windows finally had something like bash. But back then I didn't use Windows.
More recently I had the need to do some scripting for Windows so naturally I
looked at Powershell and was excited thinking it would "just like home". It
was awful. More like writing Java code than scripting. Except weirdly
heterogeneous and ad hoc. I also had to use weird hacks to stop it corrupting
every text file with BOM crap.

I can't help but thinking the praise Powershell got is just because Windows
people have suddenly realised there's more to life than point and click. Well
no shit, guys. This is why we've been using Linux this whole time.

