I think passing around real objects instead of character strings is cool. It's less brittle, and you don't have to have an ad-hoc and flawed parser at every step.
back
4 comments
As someone who thinks powershell and objects are really great.. Until you want to create a firewall rule with a principal exception using the docs: http://technet.microsoft.com/en-us/library/jj554906.aspx.
:|
I love PS too but creating a new ACL is very sucky too.
I think PS is so good it exposes the really shit bits MS built decades ago but covered up with a pretty UI.
I'm sure they'll eventually make a pass over these crap parts and refactor them. This must be what they mean by an API driver vs Text driven OS. At least anything nix you just have to spit out a text file and you're good.
Something like a Python/Ruby/whatever REPL with shell functions? Something like 'ls' would return an array of objects describing files, like:
def name(text):
return lambda file: file.name.find(text) > -1
ls().filter(name('.txt'))
> Something like 'ls' would return an array of objects describing files
You probably think of type-safe pipes similar to Go channels.
I was actually thinking I'd like a Go-like CLI. Realistically, I probably more want to convert a couple shitty shell scripts into proper Go programs and keep on using bash where it is appropriate.
So, shell commands that produce and consume JSON?
No, objects. Non-text. Real data. Plus methods.
Read a PowerShell primer to better understand this. PowerShell is geniusly designed and horribly implemented, so there's little point actually using it, but UNIX could really really use some of its ideas.
PS is absolutely essential if you are stuck administering Windows machines (esp. large numbers of them in a server farm). It makes working with Windows (mostly) tolerable if you are using a reasonably modern Windows version (2012+).
Powershell has some nice features like native arrays and hashmaps which can be mixed together into complex objects and then converted to JSON. Combined with native web request cmdlets (Invoke-RestMethod et al) it makes interacting with web services easier than the bash equivalent, where you have to use curl/wget, string munging and jq (which isn't usually part of the standard install).
It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. And classic pipes are not so bad as PS evangelists saying. PS “objects” are basically .Net objects and you can't easily write python or perl applications compatible with PS features.
> It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies.
This is not true. In fact, despite its many flaws, PowerShell did solve this particular one: any object stream can also be rendered as a string. This is exactly what happens when you just type `ls` into a PowerShell window.
I can completely imagine that a UNIX `ls` implementation would return a stream of objects (not necessarily .NET objects - just some runtime's native object format) that, when called .toString() on, would return exactly the same textual output as common UNIX `ls`. Then, you'd need a way to differentiate between two pipes. Maybe with syntax (i.e. | for string pipes, [] for object pipes, whatever) or maybe through magic ("hey, these two processes both have the capability to pipe objects instead of characters, let's tie them together as objects" somewhere at the shell level). I'm not sure how feasible either are, but I'm sure you can imagine that this problem could be solved. Then, if the shell sees that whichever process accepts the output of `ls` doesn't understand objects, just text, then it calls `.toString` on every object and renders that to oldschool character stdout.
>It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies
So?
For one, you could redesign the basic utilities too. Or offer a sumplementary revamp versions of some.
Second, you could use them in a less capable "text mode" and still get all the other benefits from the new shell.
>And classic pipes are not so bad as PS evangelists saying.
Well, they are not that relevant to 2014 either.
Colin Walters tried with Hotwire Shell [1]. However, it has been abandoned for years.
1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...
What makes you say PS is horribly implemented ?
Just a bunch:
Doing really common things, such as "find the directory of the currently executing script" can only by done by copy-pasting a non-trivial 3-line function from Stack Overflow. In batch (of all scripting languages), it's "%~dp0". Cryptic, yes, but at least it's in there. Similarly, the internet is full of blog posts with 1000-word articles explain how "easy" it is to do something in PowerShell that should've been a one liner to begin with. Basically, the builtins just suck. Batteries included? No way.
Someone at the MS marketing department decided that, in order to make PowerShell popular, it has to be cool. As a result, the above-mentioned blog posts contain example code like `echo "I Love PowerShell"`, making it sound amazing that should-be trivial stuff is only a matter of copying five lines of code [0].
In general, writing PS scripts is a really odd mishmash of bash-isms, batch-isms and .NET-isms.
Because PS is such a weird mismash of things, the ecosystem generally consists of people who don't even try to understand what's going on, but just hack some stuff together until it kind of works. This makes online resources, well, less useful than they could be.
Writing stuff that works like native Cmdlets is weird. You can make functions, but they're not entirely the same, and if you really want Cmdlets, you have to use a .NET language. I really wonder why the hell there's such a fundamental difference between functions and Cmdlets, they could just be the same thing. I also wonder why PowerShell can't just be a real .NET language just like all the others. It's a weird half-assed-in-the-middle thing.
[0] http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-sc...
Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. These two things (combined with the insanity that is Technet) result in frequently less-than-helpful Google results when researching a particular problem. More often than not the first Stackoverflow result is either flat out wrong or non-idiomatic.
It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup.
Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem.
In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.
Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future.
In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly.
For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists.
If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.
> "find the directory of the currently executing script"
Did you miss `$PSScriptRoot` ? Can piping that to split-path help you out?
Since PS 2.0 you got to write completely equal cmdlets in PS or .NET there's no different at all anymore.
Your link is dated 19 Jun 2007 which would be PS 1.0, 2 years before windows 7 came out. Were on 4.0 now 6 years later maybe it's time for another look.
I feel your reference experience with PS is out of date. You get to grips with how the get-help platform works PS is amazingly consistent. Where it isn't is busting out .NET.
Hmmm, cool! Indeed my experience is 3-ish years old. I'll give it another chance next time I need something like it! Thanks for pointing this out.
ksh allows you to define and return types - their declarations are very close to those of C++.