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!
A shell with telemetry. Insane.
Two Months with Powershell on a Unix
41–50 of 113 posts
Re: Two Months with Powershell on a Unix
#42While 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…
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 serializi…
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.
Re: Two Months with Powershell on a Unix
#43Shameless plug: if you like the idea of processing structured data in a shell, you might also like Elvish ( https://elv.sh/ ).
This is the exactly the type of comment I came here for, thanks!
Re: Two Months with Powershell on a Unix
#44> 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.
Re: Two Months with Powershell on a Unix
#45Earlier quoted context omitted.
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 serializi…
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…
> support for native PowerShell in 'ls', 'find', 'grep', etc...
There is: ls == gci, find == gci | where -eq ??? grep == select-string
and most of these come aliased to what you're used to (at least on windows).
Re: Two Months with Powershell on a Unix
#46> 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 | ..…
>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)"; I posted an alternative way to write this in 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.
Re: Two Months with Powershell on a Unix
#47> 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 | ..…
>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 si…
Thanks for the clarification.
Re: Two Months with Powershell on a Unix
#48> 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 | ..…
[deleted]
Re: Two Months with Powershell on a Unix
#49Note 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.
Re: Two Months with Powershell on a Unix
#50I 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.