Need some description up front, not in the 5th section ("Philosophy" https://github.com/nushell/nushell#philosophy). Some ideas:
"powershell for unix", "structured pipes", "pre-parsed text", "small, useful, typed tools loosely coupled."
"powershell for unix", "structured pipes", "pre-parsed text", "small, useful, typed tools loosely coupled."
- Typed object streams, which gives you stuff like autocomplete, IDE support, and generally there's no need to muck about with sed/awk/xargs - Very fast, it's absolutely fine to read a file line by line, and parse it in a script, whereas doing the same in bash/awk is a ton slower than clever use of cat/grep/wc (and a myriad of other tools) - Due to type information being retained, it's a lot easier to figure out what a given script does, without having to know how the output of a given tool looks like, given it's particular command line switches.
This is just my opinion, but PowerShell is a lot more geared toward people like me, who only write a script once in a blue moon/muck about with the build scripts occasionally, while Bash is more geared toward veteran sysadmins who live and breathe this stuff.
Or it follows the opposite mentality and the sell comes with batteries included?
I'm thinking of some arbitrary example, like downloading a JSON and parsing it to obtain some nested sub-property. In Bash world you would use the shell to execute at least something like `wget` to do the download part, and then run `jq` to parse the JSON and select the desired property. Both of `wget` and `jq` are independent programs, installed separately, with their own input & output channels, that you combine together by using the shell itself.
How would this work with PowerShell? (feel free to use some other example that might be better suited)
powershell offers cmdlets which let you sort and filter these result objects based on object property values rather than sorting on plain text values.
Obviously when printing to stdout or stderr, THAT bit is plain text, but until that very last step of displaying in the terminal, powershell results are objects.
So, that gives you a form of type safety, which isn't strictly possible in text-only shells. Powershell uses reflection to inspect the objects since the exact type of a response may have never been seen before. You can write your own cmdlets which return your own types and you can modify types returned by cmdlets using operators like 'select'. So, it's type-safe but not like everyone is used to. Powershell cmdlets always return objects (or errors, I guess), but the structure of those objects isn't always known until runtime. You can still use those never-before-seen types with the standard operators like sort and select, too.
Powershell also offers output conversion cmdlets which let you output to CSV or a textual table or a list, which is helpful when the next step in your pipe chain is a tool that expects textual input or a csv file. One can also write their own output formatters, of course.
In those ways, powershell and nushell appear to have the same goals. I haven't looked at nushell any more closely than it would take to notice this, so there may be other similarities I haven't noticed, yet. I'm sure there are many differences that I haven't noticed yet, as well.
Regarding the objects themselves, the way you describe them makes me think of Javascript objects & arrays: you don't need to know the exact shape of an input object, as long as it has the specific properties that you want to work on. Same for arrays: regardless of their content, the language allows you to use the standard ops like map() or find() (and it's then a matter of you providing adequate functions to access the contained elements)
To download json over rest you would use Invoke-RestMethod or irm.
To convert json to objects you would use ConvertFrom-Json.
To select properties from objects you would use Select-Object or select.
Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1...
Note that I used Invoke-WebRequest instead of irm here.
If ConvertFrom-Json & Select-Object were not builtin, how much information about each other would they need to cooperate? Can an unrelated change in ConvertFrom-Json's output break corresponding Select-Object command? How much are they intertangled?
To your point, all cmdlets adhere to an interface so they always return and receive typed data. They don’t really need to know anything except that they’re receiving or giving powershell objects.
Non built in commands (native binaries) just pipe a stream of bytes just like any posix shell.
Select-Object (in this instance) selects a property from the object.
An unrelated change in ConvertFrom-Json wouldn't change it's basic nature which is to convert json into something you can manipulate with other PowerShell cmdlets.
I really like the consistency that those commands have: ConvertFrom-<ConverterFormat>.
No built in converter for the format you need? I'm just speculating here, but I guess you just need to implement this or that Interface and there you go.
You can also just write a function in your profile.
[0] https://docs.microsoft.com/en-us/powershell/scripting/develo...
On linux...it seems both redundant and just plain weird for weirds sake. There are literally dozens of alternatives on linux that have a sane syntax and are likely preinstalled.
It's not a good interactive shell environment though. The commands are way too verbose and the syntax feels clunky for keying in.
[0] tab complete works on cmdlets, switches, and variables.
Same for switches and parameters. You don't have to miss `rm -rf foo/`, it's just `ri -re -fo foo/`
The module system is also not great for distributing little configure snippets like Oh My Zsh or something, it's clunky and over-complicated for that.
Isn't this how modern tab complete works everywhere? bash 5.1 (the shell I happen to be running right now, and which I mention because I think of its out-of-box tab completion as pretty basic) tab completes variables.
We use it for automation in our .NET codebase (which is being developed on both Windows and Linux) instead of bash scripts because of that and the fact it's preinstalled in the .NET SDK Docker images
Quick examples:
- Accelerators for data and conversion tasks. For example, reading a file with `Get-Content` (or frequently in the shell, the alias `gc`) and parsing and converting into a traversable, queryable XML: `[xml]$myXml = gc my-file.xml`. Then you can go `$myXml.customers.firstName` or use an XPath query.
- To get the difference between two dates, `[DateTime]::Now - [DateTime]'2021-01-01'` returns a `TimeSpan` with the elapsed hours, days, etc. It parses the date string for you because of the `[DateTime]` before it.
- The cmdlets for system administration. For example, exporting processes that use more than 200 MB of RAM and their image paths to CSV: `Get-Process | where { $_.WorkingSet -gt 200000000 } | select ProcessName, Path | Export-Csv memory-hogs.csv`
The only PowerShell tool I did love was posh-git [0]. Thankfully, someone has ported it to bash/zsh as posh-git-sh [1].
docker network inspect webservers -f '{{ range.Containers}}{{.IPv4Address}}{{end}}'
Must admit, I am no big fan of ps syntax - too verbose for interactive use - too unfriendly for scripting..
Also if you are managing Azure from Linux or macOS.
The unix way of text streams and tools to manipulate them are too ingrained that I haven't bothered to get in detail, but I hear some people are fans.
It's hard for me to criticize it because I haven't used it, but it looks like it was designed by a committee and overdesigned. I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem. It looks like some boss decided: "They have shells, so we should have it also. But we will make it much cooler. So, let's gather a committee of 500 of our best managers and let's decide what features it should have".
It looks artificial and inconvenient to me unlike Unix shells. Maybe I'm wrong. But I'm pretty sure that even syntax of PS makes it harder to type the commands. Unix commands are very short (many are 2-4 letters long), all lowercase and do not contain characters which are hard to type (e.g. `-`).
Part of why PowerShell may seem not quite Unix-like, is Snover didn't just look at Unix as an influence. Snover's professional background included experience with IBM OS/400's CL shell and OpenVMS's DCL, and his experience with both systems influenced PowerShell's design.
The idea to tie it with .NET and COM+ on windows is the best a shell has ever done, though someone noted in another thread that it is an old idea from XEROX mainframes (not sure what the name was).
if you want to imagine this in terms of unix/linux - it would be something like having all libraries' APIs at disposal directly from a shell that passes structured objects. or python's REPL being more shell-usable or JVM having a shell that provides access to all classes in a click of ENTER.
major downside of pwsh is that you can feel it being slower than expected due to the way objects are passed around, but I really expect this will be solved at some point with future releases as PWSH as language is still being developed so some concepts and internal architecture decisions perhaps change a lot.
noshell is taking this idea to a fair level, but really, there is a reason to do some dev/devops work in PWSH because it will heavily impact all future shell development even if eventually superseded by something better.
There's a very long road for any shell to get where pwsh is within MS's ecosystem (and even within .NET Core/GNU ecosystem). And I can easily imagine .NET Core wrapping DBUS and other COM-like facilities available for GNU OSs.
But what's the "business case" for iteration, conditionals, addition - apart from "everyone needs these"? Though these probably weren't the features he was thinking of.
You think iteration, conditionals, addition are not needed in shell scripts? It would be a very unusual position indeed.
Or could it be that you are not familiar with the expression "business case"? (Sorry if this is off base! but the word "mercenary"in your post also kind of points this way).
"Business case" has very little to do with business as commercial enterprise...
> I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem
Interestingly enough, it is used for automating Windows configuration.
Re last paragraph:
UNIX commands are random letters that are like that due to historical reasons — if you don’t know one exists, you can’t find it. And when you have to use {} in PS you are dealing with something you would do with awk sed with even more arcane syntax — PS is pretty readable with some knowledge on any PL. Also, they are Verb-Noun based so you can get around and find commands even offline (though Noun-Verb would have probably been a better decision). Due to the fixed syntax they can be shortened very well. Also, due to every “command” having the same conventions, arguments are properly done (no tar xf or -xf or —extract), they are reliably autocompletable without black magic, and they are also autocompletable by giving enough letters to make it unambiguous. So while I am not particularly fond of Microsoft, powershell is better than bash (though frankly, what isn’t?) in every conceivable way.
There are fair criticisms to be made of bash...but this isn’t a fair comment either; I use power shell a lot; I’ve written hundreds or thousands of lines of powershell glue for scripts and devops pipelines and all kinds of things.
It’s not very good.
It is one of those things that seems like it’s a great idea; everything is an object, don’t serialise between jobs, tab completion on related objects, verb-noun commands... it reads like a feature matrix.
The reality is less ideal.
It’s verbose, the commands are arcane, and the verb-noun thing breaks down into meaningless pairs in many cases, particularly in the azure commands, or worse sql server commands.
Maybe, to be fair, there is a core of elegance in there, but powershell displays a fundamental failure:
When an application doesn’t have to do the hard work of making a good cli, the resulting commands in powershell are actively user hostile.
It’s a pattern I’ve seen over and over again; and things like the az-cli are a tangible acknowledgment from Microsoft itself that the results have been substandard, and rejected, overwhelming, by the broader community in favour of arguably inferior tools (eg bash).
So... you might argue “network effect”, but I don’t buy it; powershell isn’t friendly; not to new developers, not to “clicks ops” developers, not to Unix developers.
It’s firmly a middle ground “no one wants to use it if they can avoid it” product.
Bash scripts, now there is literally a hell on earth... but bash itself? Works fine.
/shrug
No way, I love PowerShell. It was my first choice for the bulk of a B2B Windows integration product. Part of it's a C# desktop app; the rest is PowerShell scripts that customers can edit to taste.
I reach for it all the time in projects. The pipeline is so clean to work with. Once you get used to how it handles collections, the cmdlets are very intuitive, and PowerShell Gallery has a large selection available for download.
Objects instead of strings is big by itself, of course. Then you get the .NET standard library right in the shell to interact with them. Great for parsing dates, numbers; a powerful regex engine; stream manipulation; pathing functions; the ability to write and execute C# in the shell; etc.
The cmdlets for data manipulation have gotten very good, too. The CSV cmdlets used to be unintuitive because they exported type data, but that's now off by default. `Import-Csv` and `Export-Csv` work with objects that you can easily manipulate with the set operations cmdlets. It feels very much like LINQ.
Same with `Invoke-RestMethod` (`irm`) when interacting with APIs. It deserializes JSON into objects automatically. You can then easily filter or transform the result.
There's a learning curve for sure, but once you get past that, it's a very good shell. I feel like it's one of the best things to come out of Microsoft.
It's just that I feel uncomfortable even looking at the PS syntax. Maybe it's idiosyncratic. Maybe I've spent too many years in Unix shell.
The only reason anyone accepts it is that it has always been there. But if you actually look at it critically, it is hot garbage.
Another great feature is named parameter support. It's so much easier to deal with parameters than with other languages I've used.
You’re just familiar with the former and not the latter currently.
It's just an overall bad argument. I don't see how `Get-CimInstance -Class Win32_OperatingSystem` is in any way memorable
If you have more than one installed, `man` might decide to show the first one or it may interactively ask you to pick one, depending on whether it's been configured to be "posixly correct" or not.
i personally would've put much more weight into the ease of reading and understanding the code.
personally, i think that PS just came too late, so most people (me included) are too used to the way the unix shell works/feels. It would have to be just straight up better in all regards to displace it, but its more like a different flavor entirely. It however a very interesting take on scripting, in my mind it was more comparable to python repl then bash though, but i haven't really used it much.
I'm getting confused here, Isn't that literally what I said?
I said that a lot of people (me included) are more used to Unix shell scripting. If PS had been released 30yrs ago, things wouldve probably been different. People have however already become comfortable with Unix shells, so it needs significant improvements to convince them to switch the tool of choice. While PS does have improvements, they're not significant enough to relearn everything.
To me, Unix scripts are more readable though, this is simply because Ive been writing them for so many years now, while I barely touched any PS code.
I was initially very biased against PS as well, but then had to learn it and I found the design quite genius. At a time I even tried to use it as a daily driver on linux but my muscle memory is UNIXy, and there are a few edge cases that are harder in PS than in bash so I had to revert back. But we should strive to keep an open mind even about Microsoft technology :)
The thought process was more like "You can either hire a dude to do it by mouse in MMC or you can get someone with a masters in CS to do it in DCOM. We need a middle ground."
Source: was in the room
MMC can control remote computers, but I believe only one at a time? Unless it's something through Group Policy.
Now, the APIs exist to do all this remotely (DCOM), but good luck discovering what they are! And the minimum level of program you'd need to call them would be a C# project.
So, Microsoft knew that UNIX systems had an API that was interactive, scriptable, discoverable, and composable, all the things which CMD and MMC and DCOM aren't. So they decided to build one. And make it object-orientated. It's actually pretty good for the administration use-case, but for more general work it feels weird. And it doesn't interact with text files anywhere near as good as shell does.
IMHO Microsoft went all-in on the object-oriented paradigm and tuned the operating system to work with C++ ABIs and expecting administrators to use tools that use Microsoft or vendor provided DLLs.
First of all your backstory is wrong, it was a 1-person project. Then, about the features, all those long, explicit commands have short versions.
Secondly, I agree that Powershell feels a bit alien on Unix, which will probably be the main reason its adoption will never be amazing.
In general I really dislike "[some other product] for [a different use case]". It might be accurate but many potential users might never have heard of PowerShell or if they have only have a vague idea of what it is.
It's not hard to imagine the same for PowerShell.
1. parse a json value from stdin and set it as the initial result
2. for each function, apply the function to the result, and set the output as the result for the next function.
3. The final result is pretty printed on stdout.