
Two Months with Powershell on a Unix - joejag
https://code.joejag.com/2020/a-month-with-powershell.html
======
jlgaddis
If you don't want PowerShell reporting your activities back to the mothership,
don't forget to set

    
    
      POWERSHELL_TELEMETRY_OPTOUT=1
    

in your environment before launching PowerShell!

~~~
amedvednikov
A shell with telemetry. Insane.

~~~
TeMPOraL
Reminds me of a certain package manager with telemetry. Homebrew, was it?

~~~
Fnoord
Opt-out telemetry, specifically. Debian had popularity-contest (popcon) long
ago, but it was voluntary (opt-in).

Regarding Homebrew, "Wonder if its GPDR complaint."

------
klodolph
I spent some time with Powershell on Windows recently, more time than I am
used to. Powershell is a clear winner over CMD.EXE by a mile, but…

\- As an interactive shell, it suffers from an ecosystem which is much poorer
than the bash/zsh ecosystem,

\- As a scripting language, I’m going to use Python or Go the moment anything
becomes larger than a few lines,

\- Installing Posh Git is just a really mediocre experience (indicative of
various, more specific problems)

Some of these things can be fixed up, like the bad experience installing Posh
Git—you have to update the package manager to a non-release version, but the
signature is occasionally broken (it seems to happen again and a gain) so you
have to disable signature verification, and then you can use the updated
package manager to download the Posh Git package.

Through the journey I encountered so many stupid random problems that it’s not
something I can just step out and recommend to anyone. I’ll continue using it
as my primary shell on Windows, but for various reasons (I forget the exact
details) I had to give up on it for working with Git. There was a lot of
“action at a distance”, like running ssh-agent would break the “ls” alias for
Get-ChildItem, which leaves me high and dry without muscle memory.

Meanwhile, Microsoft is also spending time and money on WSL. Again, I’ll still
be using PowerShell on Windows but even there it is a damn rough experience.
The command-line has been paradoxically a second-class citizen as well as a
necessary tool for development on Windows for as long as I can remember, and
it will take a lot more improvement to PowerShell before that feeling
disappears.

~~~
beart
My biggest issue with powershell is how undiscoverable it is. Good luck doing
anything without searching for commands in a web browser.

But maybe that's just a result if it being so new. 'ls' has been around for
almost 50 years...

What it really feels like is a complete programming language inside of
notepad.exe because of the historically terrible windows command prompt.

~~~
nsomaru
Yes, but, POSIX shells aren’t that much more discoverable, either.

It takes loads of reading and trial and error to become competent in any
command line.

~~~
solarkraft
The worst/easiest to fix discoverability problem with Microsoft prompts is
that they show you a single completion on tab and cycle through them on every
subsequent tab, which is a lot more confusing than being shown all the
options, in my opinion.

------
dijit
Dude has more patience than me.

I tried running powershell on linux a few times, and every single time the
second command I run is not supported on linux.

I don't even remember what the commands were, PSremoting was one for sure and
I think another was Invoke-WebRequest.

Powershell on linux is a nice idea but in the current form it is in name only,
as nearly nothing works.

~~~
m0xte
I’m not sure I could cope with that. I have enough problems with it on
windows. Literally every corner you turn something punches you in the balls or
turns to dust in your hands. It’s one of the most frustrating things I’ve ever
used and I avoid it where I can.

I would not invite it onto a *nix machine voluntarily where there are
established patterns and solutions which have matured over the space of 40 odd
years now.

~~~
munchbunny
Where does that happen for you?

In my experience with PowerShell on Windows, you have to approach it more like
interactive python with shortcuts rather than a regular shell, and once you’re
accustomed it works fine. The main issue is that it doesn’t work like a
classic shell, it just has some affordances to look like a classic shell in
common use cases.

~~~
m0xte
Well it’s not the concept but the implementation that is at fault. From
persistent random WinRM failures, sudden things breaking and the whole thing
wrapping rancid bits of WMI and COM which leak through regularly, it’s just
pain. On top of that the interface is somewhat flakey and slow. Plus some of
the semantics feel like going back to circa 1995 Perl. Oh and don’t get me
started on the nightmare that is script signing and security which really does
nothing useful other than get in the way.

It really feels immature.

The biggest travesty is when it is integrated into something else such as
ansible, packer, chocolatey etc where it will cost you a couple of days
occasionally due to some obscure issue hidden behind even more layers.

------
xiaq
Shameless plug: if you like the idea of processing structured data in a shell,
you might also like Elvish ([https://elv.sh/](https://elv.sh/)).

~~~
xrd
This is the exactly the type of comment I came here for, thanks!

------
Arnavion
>For example, if we wanted to get the first three files from ls I’d do
something like `ls | head -n 3`. In Powershell, it’s `$(dir)[0..2]` since the
dir command is returning an array which I can index into.

You could do that, but the way to write it in the bash way would be `dir |
select -first 3`

>a quick Google told me to use `echo | openssl s_client -showcerts -servername
joejag.com -connect joejag.com:443 2>/dev/null | openssl x509 -inform pem
-noout -text` which works fine in Bash or Zsh. Still, in Powershell, it throws
an error for some reason.

It won't throw an error (unless you're running it without a tty), but it will
ask you to enter the parameter of `echo`. That's because `echo` aka `Write-
Object`'s parameter is required, unlike bash's `echo`. `echo |` in bash is the
same as `< /dev/null`, but that also doesn't work in pwsh because it doesn't
support `<`. The pwsh way is to pipe `$null`, thus

    
    
        $null | openssl s_client -showcerts -servername joejag.com -connect joejag.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

~~~
smacktoward
The echo problem is reflective of a larger, longer-term issue with PowerShell,
that being that it sometimes aliases PowerShell commands to the names of
equivalent Unix commands. That’s done to ease the transition into PS-land for
Unix folks, of course. But unless the PowerShell command works _exactly the
same_ as the Unix command it’s aliased to — takes all the same arguments,
returns all the same data structures and error codes, etc. — you inevitably
run into cases where things break because echo or curl or whatever aren’t
behaving the way your code expects them to.

~~~
Arnavion
True. I used PS only on Windows for many years and got into the habit of
writing `cat`. When I started using PS Core on Linux I had to unlearn that and
start using `gc` instead, because `cat` there is the native `cat`

------
pcr910303
While I really would like UNIX shells to get the ability to pass structured
data, one problem is that most shells out AFAIK there don't give the ability
to pass structured data natively.

For these structured shells(like Powershell, elvish, Nushell) to succeed, they
should...

* have a spec on how to pass structured data from a native executable (without function calls like 'from-json')

* implement some structured data functionality in all GNU coreutils at the very least

* and push the 'structured shell evangelists' to implement these schemes on other programs.

~~~
jodrellblank
That is unlikely to happen in PowerShell because the structured data is .Net
objects. If you are writing a C# cmdlet, it runs in the PowerShell executable
process. That is, the output is not structured text it's live state, open file
handles, methods, in-memory structures, whatever you want. You aren't going to
do that from a native command running in a separate process returning data
through stdout without serializing it - and then you're back to convertfrom-
json as far as it matters.

> For these structured shells(like Powershell, elvish, Nushell) to succeed,
> they should...

For PowerShell to succeed, Microsoft should rewrite all the GNU coreutils? Did
you see the months of outcry when Microsoft used the four characters "curl" in
PowerShell? You reckon anyone is going to want unilaterally rewritten
coreutils? From _Microsoft_?

Microsoft should stop on their development of a completely new tool and hobble
themselves to the constraints of the stuff they're trying to replace,
controlled by people they're in competition with? Unlikely fantasy world.

~~~
pcr910303
Firstly, I wasn't writing the comment specifically about PowerShell - it was
just a rant about the structured shells.

> That is unlikely to happen in PowerShell because the structured data is .Net
> objects.

Isn't that an implementation detail?

> You aren't going to do that from a native command running in a separate
> process returning data through stdout without serializing it - and then
> you're back to convertfrom-json as far as it matters.

Not having to write 'convertfrom-json' IMHO is a big improvement. 'ls[0..3]'
is much more convenient than 'ls | from-json[0..3]'. (Imaginary syntax, BTW.)

> For PowerShell to succeed, Microsoft should rewrite all the GNU coreutils?

I wasn't really talking about PowerShell either, but well, yes I do think that
for PowerShell to succeed there should be support for native PowerShell in
'ls', 'find', 'grep', etc...

> You reckon anyone is going to want unilaterally rewritten coreutils? From
> _Microsoft_?

It doesn't to be 'rewritten', it just have to gain support. I don't think that
a set of patches that adds a new output format will be that problematic. And,
one doesn't have to use PowerShell support if one isn't using PowerShell.

> Microsoft should stop on their development of a completely new tool and
> hobble themselves to the constraints of the stuff they're trying to replace,
> controlled by people they're in competition with? Unlikely fantasy world.

Er... you know - nobody said that one should replace your bash with
Powershell. If you decide that the 30-year-old-unable-to-handle-spaces-in-
filenames-by-default script language is fine for you, then you can keep using
bash. They're not EEEing...

BTW, checkout elvish shell, since it's not from MS and it has some good ideas.
You might like it if you're just hating PowerShell b.c. it's from Microsoft.

~~~
jodrellblank
> > That is unlikely to happen in PowerShell because the structured data is
> .Net objects. > Isn't that an implementation detail?

Arguably, but I don't think so. They stopped writing a language spec at
version 3, but the spec which exists[1] says on page 1 " _Windows PowerShell
is built on top of the .NET Framework common language runtime (CLR) and the
.NET Framework, and accepts and returns .NET Framework objects._ " so that's
in the spec. Either way, there is only one PowerShell implementation to speak
of so if you want GNU utilities to emit structured objects to PowerShell
without going through the serialization to JSON/CSV step that you want to
avoid, you will practically have to add interprocess communication into the
running process of a managed language and emit .Net objects, and that will be
a difficult push.

If you built an implicit decode-from-JSON step into running native cli
commands, as Invoke-WebRequest has for talking to REST APIs, you could get
more convenient syntax but they will forever be second-class citizens. They
won't follow the Get-/Set- verb naming scheme, they won't be built to take
pipeline input or handle command line parameters in the same way, they will be
limited to only output which can be serialized to text.

By the time you've updated `ls` to read [System.IO.DirectoryInfo] through
stdin, detect if it's running inside PowerShell and return serialized
[System.IO.FileInfo] output to stdout, and rewritten PowerShell to auto-
convert output like this to objects, you may as well have used Get-ChildItem
instead.

> _I don 't think that a set of patches that adds a new output format will be
> that problematic._

See
[https://news.ycombinator.com/item?id=12319670](https://news.ycombinator.com/item?id=12319670)
/
[https://github.com/PowerShell/PowerShell/pull/1901](https://github.com/PowerShell/PowerShell/pull/1901)
for the kind of hassle that just being microsoft near Linux causes.
Unilaterally patching coreutils for Microsoft-specific behaviour will have an
apoplectic body count associated with it, I reckon.

[1] [https://www.microsoft.com/en-
us/download/details.aspx?id=363...](https://www.microsoft.com/en-
us/download/details.aspx?id=36389)

------
alkonaut
The problem with powershell on Unix/Linux is that there is an implicit
assumption everywhere that there is a shell available. If you look at simple
git StackOverflow questions like "how do I get the oldest common ancestor
commit for two branches", you'll happily see people answer with combinations
of shell commands that assumes that there is a sh (or some times even bash or
zsh!). Absolute madness that git can't do basic things without relying on
external applications that may or may not exist.

~~~
bragh
It's not madness, it's the price of flexibility and one that I am personally
gladly to pay. I am forced to use Windows and pre-approved tooling daily at
work, you can't imagine what a relief it is to use Linux at home, where you
can chain together the exact programs that you want and make them work the way
you want.

~~~
alkonaut
I don’t mind that programs provide output that can be chained and so on, but
what annoys me is when portable (cross platform) apps m, like e.g git, doesn’t
provide _core functionality_ without the assumption of a specific environment.
It's fine to let the user sort the outputs using an external program. But if
the sorting is so commonly required that it's a "core feature" then perhaps
the program itself should do it.

Since most developers use windows, most windows users use cmd as their shell
and git is the most common vcs around, it wouldn’t surprise me if the most
common environment for git is ... Windows cmd. Where there is no sed/grep/awk
etc!

~~~
sixbrx
I'd suppose most WIndows users using git either use it through a UI
(e.g.Intellij's), or else in the bash shell for Windows that comes with the
git package for windows. Starting that bash shell is easier than mucking with
the path and the old cmd.exe is awefull in so many ways, anyway.

------
louwrentius
I am dead serious. Powershell should replace (bash) shell scripting under any
Linux.

I find shell scripts terrible, I've learned to switch to Python quickly,
despite the overhead.

Powershell is very command-line friendly, with easy tab-completion of
commands. I've worked with it extensively on Windows, creating large
worklflows with it, it's very nice.

Powershell even has a unit test tool called 'pester' which is funny to me
because it means 'bully' in my native language.

~~~
geocrasher
I don't know what your native language is, but in English "pester" means to
annoy. A negative connotation no matter what.

I don't get the hate on Bash though. It's a natural extension of the command
line, and works quite nicely to get a lot done _without_ the overhead.
Deployment is a lot easier in my environment (web hosting) because all of the
servers are homogenous, and I don't need to worry about any dependencies
because I rely mostly on coreutils + grep and awk.

~~~
perl4ever
>I don't know what your native language is

Dutch?

------
zenexer
Note that this article is slightly out-of-date. It looks like the experiment
began in January with PowerShell 6, and there are notes about caveats that
were scheduled to be fixed with PowerShell 7. PowerShell 7 has since been
released.

------
ggm
"so they do these cool things, which of necessity break a model some of you
will have been familiar with for 50 years in some cases, but its amazing"

(in my case, 40 years.)

There is considerable merit in new things. But there are also costs. And,
there is the proplist version of this story in OSX. So, I know this is a
"thing"

~~~
jabits
There are often more costs in sticking with the same tech for forty years...I
would still be coding for DOS...I hope with new generations of devs will come
better tools...as well as a greater willingness to move on...

~~~
fapjacks
Why? Are you afraid your software is going to wear out on you?

------
beagle3
One of the missing ingredients in PowerShell when I tried to use it was
network transparency - which I suspect will be hard to solve since it passes
.net objects around.

It is not often that I pipe things into or out off ssh, a Unix domain socket
or a pipe, but when I do it’s usually significantly easier and more efficient
than other ways.

I also often save outputs rather than pipe, to inspect/debug, or avoid re-
computation.

I last played with PowerShell on Win7 ages ago so things might have improved
dramatically (e.g. if every output is guaranteed to round trip serialize with
a network stream).

------
jlgaddis
I installed PowerShell on a Debian machine a while back so that I could use
(VMware's) PowerCLI modules / commands.

That worked well enough -- exactly as on Windows, AFAICT -- but I can't
imagine ever trying to replace my "daily shell" ( _zsh_ , in my case) with it.

------
nailer
I've been using Unix for 20+ years, switched to pwsh as my main shell 4 years
ago (on both Windows and macOS).

Here's my notes: [https://github.com/mikemaccana/powershell-
profile/](https://github.com/mikemaccana/powershell-profile/)

Last few weeks I've been going back to bash, mainly to try out WSL/Ubuntu's
defaults, but will probably move to pwsh there too. I like the consistent
naming (which means I can guess commands) and avoiding the scraping that's
inherent in text-only shells.

nushell looks like one to watch too. It's a lot further behind than pwsh but
has a faster growing community.

~~~
yoloClin
Hey thanks for this, nushell looks really interesting! I really like the idea
of an objective shell but don't like the verbosity of PowerShell inputs. I
think if you go through my post history I actually describe wanting something
like Nushell, not knowing it existed!

~~~
alkonaut
Tbf most common PowerShell commands have short aliases for interactive use. I
like that I can use the long forms in scripting and aliases on command line.

For example in my PS (unsure who created aliases because I think some aren't
default) I have both "ls" and "dir" for "Get-Childitem", "wget" for "Invoke-
Webrequest" and so on.

------
cryptonector
> For example, if we wanted to get the first three files from ls I’d do
> something like `ls | head -n 3`. In Powershell, it’s `$(dir)[0..2]` since
> the dir command is returning an array which I can index into.

Hmm, yes, but it's not a lazy array/list, so it's not online, is it. If you
have a few million files in a directory, that's not going to work. To be fair,
neither is `ls | head -n3` -- you have to use `ls -f | ...` to avoid ls(1)
_sorting_ the listing first, but if you do, this will be online. For ls(1)
it's not really an issue, but in general you want your shell to be online.

~~~
Arnavion
>Hmm, yes, but it's not a lazy array/list, so it's not online, is it. If you
have a few million files in a directory, that's not going to work.

It is lazy. The author slightly misunderstood / oversimplified what's going
on. The commandlet does not build an entire array in memory and then write it
out; it writes out each item one at a time. Evaluating it as `$(dir)` just
forces all its output to be collected into a single value, ie an array. It's
the equivalent of writing `output="$(ls)"; <<< $output head -n3` in bash.

I posted an alternative way to write this in
[https://news.ycombinator.com/item?id=22963842](https://news.ycombinator.com/item?id=22963842)
which does not need to build the output as an array first and is also more
natural to write.

~~~
cryptonector
Thanks for the clarification.

------
pvtmert
here is my opinion on `When X is going to replace bash?`

The story goes on like this:

You went to DataCentre, logged in to an internal machine, something happened
(eg failure, diagnostic necessary et.al.) which you need to fix.

given condition, you don't have internet connection inside (air-gapped)

\- You most likely have man-pages installed and having examples what to do in
them,

\- `--help` yields some sensible output

\- Shell is 'fast', errors are well-known and defined.

Also, take into account of other comments that are discussing `how to do x`
and why it doesn't/wouldn't work on PowerShell

~~~
pjmlp
Given that example, good luck trying to log into a DataCenter that still uses
classical UNIX with either sh or ksh as their only options.

Bash also has not replaced all other UNIX shells.

------
Rapzid
On a related tangent, I think the Powershell project is the only place to get
certain DotNet libraries that pertain to remote management. It's a bizarre
situation.

------
jodrellblank
> _and expect it to be possible when Powershell 7 comes out (I’m using
> Powershell 6 while writing this)._

PowerShell 7 was released in early March a month and a half ago:
[https://github.com/powershell/powershell/releases](https://github.com/powershell/powershell/releases)

------
0x8BADF00D
I like that it passes objects instead of strings, I could see that being
really useful. Get-Member will list all methods and properties of an object.

~~~
lpghatguy
Another shell that has a similar philosophy is Nu[1]. I think the idea of
structured shells (and typed shells?) is a very interesting path to improve UX
and prevent certain kinds of common error.

[1]: [https://github.com/nushell/nushell](https://github.com/nushell/nushell)

