Igor Moochnick announced Pash, an open source implementation of Microsoft’s PowerShell. “The main goal is to provide a rich shell environment for other operating systems as well as to provide a hostable scripting engine for rich applications. The user experience should be seamless for people who are used to Windows version of PowerShell. The scrips, cmdlets and providers should runs AS-IS (if they are not using Windows-specific functionality). The rich applications that host PowerShell should run on any other operating system AS-IS. Secondary goal: the scripts should run across the machines and different OS’s seamlesly (but following all the security guidelines).”
PowerShell was a logical step from the bash design (same basic principles: plenty of small utilities, good pipe system, powerful language), with the addition of object orientation (which is good, since it reduces the need for text parsing).
It is the dream of (windows) system admins. It brought UNIX functionality, and added some more. Now it goes back to UNIX. Gotta see how this turns out.
This is great. I was wondering if Powershell was going to be cloned.
I always love it when apps go cross-platform, or apps that work in a similar manner are created.
Except when Microsoft does it – them people accuse them of ripping off everybody else
Ahhh well, for all the bashing that MS products get, since the FOSS community are making efforts to clone what MS is doing (Mono, Moonlight, Powershell etc), they must be doing something right.
Let’s be clear – the most important reason these things are cloned by FOSS is because of interoperability – MS could/should have worked with existing tech, but of course they don’t. So a lot of work has to be duplicated.
You forgot the license Microsoft usually attachs to it’s code. They go out of their way to insure that no-one can improve the code and use it in such a manner as to weaken their own revenue stream.
So even their most open software (full code, specs and docs) prevents *ANY* commercial use of their code. This means if you even make major changes to the code you can’t use it for even you own personal use if it helps you make money, and forget about giving out any improvements if they have commercial use.
The uses of the code not only are limited, but just the fact that you look at the code makes you open to lawsuits if you write something similar in the future.
I love the ideas behind Singularity but I refuse to look at any of their “Open Source Code” as it becomes a ticking time-bomb when future OSs start having the same features and I try writting code for them.
Good for academics!!!
The current implementation of Pash is written using pure .Net 2.0. It compiles on VS 2008 as well as on Mono.
I personally don’t like .NET/MONO at all and I’m not alone at this kind of choice. Depending on a programming language owned by Microsoft is not so funny in the Open Source world, specially when there are less evil alternatives like Java or Python.
I personally find .NET/MONO slow and I will never use it because idological reasons, but that’s not the main cause. I’m also not interested in Java, both languages use bytecode so they are against resource efficiency and I try to avoid bloated stuff when possible.
I don’t understand why Pash when existing stuff like ZSH and the power of shell scripting. What are the real advantages of Powershell/Pash? I find it a lot less comfortable to use and a copycat of UNIX.
I think “alternatives” to Microsoft stuff are not interesting enough, devs like Miguel de Icaza got in love with the guys of Redmond but I don’t see what’s so good there except the money.
Edited 2008-04-07 22:00 UTC
C# is not “owned” by Microsoft.
They may hold patents on things lik WinForms and ASP .NET (Which I believe should of been left out of Mono) but everyting else in .NET is right out of the ECMA specficication.
…as we all know ECMA is completely independent.
Indeed, they are. But there’s always ISO if you prefer.
ISO/IEC 23270:2006 – C#
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail…
ISO/IEC 23271:2006 – CLI
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail….
Others (including ECMAScript)
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_brow…
Those are the same standards: they’ve only been PAS’ed by ISO.
Indeed, I’m not too keen on checking out this “cool” new Mono app. Rather, I’m looking around for my Python Cookbook to review the chapter on system administration. If I changed my login shell to /usr/bin/python and eschewed bash for a month, I wonder if I would not be a more effective admin by the end of it? You know, I might just try that…
Edited 2008-04-07 22:28 UTC
No, you won’t.
Because while shells may have programming languages, the command line is a different world and has different characteristics than that of a programming language.
Also, the python command interpreter is reasonably horrible compared to modern shells. A lot of this is simply the language itself with its indention based blocks. Popping in and out of an editor for every command is not a real practical way to work.
The closest you’ll get to a reasonable shell like environment inside of a programming language is within the Common Lisp family. The reason is that Lisp has a history of being a shell environment. The listener is not a second class afterthought in a Lisp system, but rather intrinsic to the experience. That in part is what makes it usable as a shell.
You can also look at scsh, which is a Scheme Shell — i.e. a Scheme implementation specifically designed to be a shell. It has many shell friendly features.
And, finally, anything the eliminates pipes as an idiom isn’t worth considering anyway. The “mashup” ability of piped ascii, while not perfect, is shockingly powerful and flexible.
Well, you’ve pretty well hit on all the reasons that I have not done this in the past. The thing about an exercise like this would be to see what disadvantages can be overcome with practice and experience, what advantages might emerge, and how a combination of python and command line might be superior to either alone, if only I were more fluent with that area of python usage.
Python does not have to be a better admin tool by itself for me to emerge as a better admin at the end of the month.
I wouldn’t. The standard python interpreter would make a lousy bash replacement; it’s just a convenient way to execute Python code interactively, not manage your entire OS. If you really want to try an interactive Python shell, take a look at IPython:
http://ipython.scipy.org/moin/
Thanks. This looks interesting. Funny thing. Although I have been aware of something called ipython for a while, I always assumed that it was the command to invoke IronPython. And since I don’t use Windows, I never checked it out. :-0
http://rush.heroku.com/
Rush seems to be the next thing that might make it, though the ruby interpreter would need some speed improvements, kinda like the idea.
Bash, ZSH et al may be powerful in themselves, but they’re all built upon primitive, archaic foundations: untyped data, ASCII-centric assumptions, limited IPC capabilities, crude exception mechanisms, etc. It’s like putting a Ferrari body and engine on top of a Yugo chassis and transmission: at best, a waste of potential; at worst, an exciting accident just waiting to happen.
Frankly a major shake-up has been long overdue. Powershell/Pash may or may not be the answer (they are still too young and immature to be making that call just yet), but it’s good to see someone finally having a shot at dragging the command line from its thirty-year creative stupor and introducing it to the modern world at long last.
Hotwire is an attempt to superset Unix text-stream pipes with an object-oriented approach, currently using the Python runtime:
http://hotwire-shell.org
I was actually going to poin this tool out as well. There are some issue that I have with it but it works rather well in the end.
Mono will NOT be running on my system. Someone really needs to rewrite tomboy in another language, other than that I don’t run mono at all.
Better not run a javascript capable browser either, as its under the same standards body as C# and the CLR.
Always gotta watch out for those standards based languages, everyone knows they ooze pure evil….
IE only “ECMAscript” is the number one cause of business critical sites not working in Firefox or Epiphany for my customers. I’ve never understood why people moan on and on about CSS issues when broken javascript is the real show-stopper. We don’t care if the site looks wrong. But if the page loads up fine, and when click on links nothing happens… then what?
I’ve thought about writing it up as a screenplay for a geek horror film: “Javascript: Void”. Kinda catchy sounding, don’t you think? 😉
Note that while Microsoft has made a big to do about IE8 CSS support and Acid2, I don’t think we’ve heard word one out of them about IE’s broken javascript implementation or Acid3. And I doubt we will. Because while everyone seems to be looking in the direction of CSS, they know very well where the *real* browser lock-in lives.
Its worse then incompatibilities, it is impossible to do any sort of optimization due to the interpreters all being so wildly different.
IE8s javascript (or jscript to be precise 😉 is actually getting some work done on it. They are fixing some of the horrible, horrible string performance issues (did I mention it was horrible?) and are trying to address some of the other issues as well.
Yeah. I happened upon this interesting link yesterday:
http://www.codinghorror.com/blog/archives/001023.html
and the associated link to the interesting sun-spider javascript benchmark. But I would have to disagree that the performance issues are worse than incompatibility. Incompatibility is the worst performance possible, if you know what I mean. Note from the above link that aside from the string issues, jscript apparently performs well compared to FF2. According to my own testing, it looks like, in general, FF3’s javascript engine is 2-3 times faster than FF2.
Edit: I see now that when you said “worse”, you were speaking from the perspective of a responsible producer of HTML/CSS/and ECMAscript. I see things from the opposite perspective, having to support consumers of HTML/CSS/and ECMAscript in a world where many producers are far from responsible.
Edited 2008-04-08 02:31 UTC
Mmmm, looks interesting. Will check it out.
What you’re saying is they’re not buzzword compliant. However, they are proven, effective, stable, and have huge support. Shells are supposed to be quick and dirty. Powershell is a way overengineered solution to the problem of shell scripting.
LMAO!
Its funny, I don’t like powershell because it is too much like bash and perl 😉 The syntax is quick, dirty, and absolutely hideous for something coming out in the 21rst century.
That being said, the raw power blows anything I have used before away (i’m far from an expert though, just bash and perl mostly). It really takes piping to the next level, and being able to leverage the .net framework is sweet.
Oh, please. Strawman.
Untyped data makes it a major bear to express non-trivial data structures (lists, records, tables, etc), and dumps the entire burden of reliably representing and interpreting such data on developers and users instead of the machine.
Inbuilt ASCII assumptions blithely ignore the fact that most of the world does not use English as a primary language, if at all. An inexcusable deficiency today considering that Plan 9 managed to address it fifteen years ago.
Its limited IPC capabilities make it a poor glue for more sophisticated (e.g. event-driven) desktop and net environments.
Its lack of decent exception handling is just plain embarrassing. Compare with [e.g.] interactive Smalltalk environments that allow users to halt execution, make changes, and resume from where they left off, and tell me how the shell way is quicker, easier or more convenient.
There is a difference between quick and dirty, and restrictive and crude. Some of us would like to enjoy the former benefits without having to pay the latter penalties for the privilege.
You can dismiss it as much as you want but standard Unix shells’ lack of support for Unicode and basically any data that is not 8bit ANSI magic-number-terminated text is sad to say the least. And that’s without considering the demented wildcards or the syntax.
Of course, when you want to break a skull anything looks like a hammer.
MS’s Powershell is an improvement over UNIX shells, however, I fail to see how Linux as it is would benefit from a .NET object-oriented shell. Not even current Windows benefits from it. Short of rewriting the whole userland in .NET, it is useless bloat. For regular applications you use real languages, not scripts.
Except that any modern distro has full support for Unicode. Everything from dumping the contents of a unicode file onto the screen for a peek, sorting, editing, and on and on. Repeating this outdated idea that only ANSI is supported is sad to say the least.
$ NAME=”山太郎”
$ test $NAME = “山太郎” && echo unicode supported
unicode supported
Edited 2008-04-08 12:23 UTC
It’s not bash, ls or rm that support Unicode, they just ignore multibyte characters, it’s the modern X Terminals of major DEs that do. And it’s just UTF-8.
But if you want, you can make that a fake-multibyte magic-number-terminated bag’o’bytes. It doesn’t change its being a technology from the 60s.
You can do and you do do many things with it, but I dare to say many of those things would benefit from being passed as objects instead of plain text. Even text would benefit from being passed as a string object.
That you can script the hell out of the text output of a program and pipeline it as meaningful input to another one is cool, but that doesn’t mean it is the optimal approach.
No, you’re just plain wrong. Many editors, command line tools, and basic Linux commands are all now Unicode aware. For instance the “sort” command is locale aware and will use a proper Unicode collating sequence and not some 1960 ASCII alternative.
Okay point taken. Apparently since 2002, UTF8 is supported in bash if it is the current locale and it is doing the right thing:
main=多é‡ç¶™æ‰¿
echo ${#main} #returns 4
I was probably having locale problems before.
But still, can it get the file MIME type from an hypothetical ls# returned file object? Can it append string objects from different locales? Can it bind public interfaces together? Yes. The question is if it is easy and how much overhead do you add to achieve that end.
If I need app1.output[i].number3 to pass it to app2.prng.seed, I can simply ask for it, or app1 can send all the contents it has in text form to stdout and script0 can then look for the data app2 is interested in in the mess.
I disagree. Text is anything to anybody. Object-orientation with binary data is only something to certain people. It’s not portable across time and space in quite the same way that text is. You may say that it’s dated, but it was a really good decision at the time and I think there’s a reason it’s still around. I mean, you wouldn’t say that we should do away with RAM because it’s been around for a while, and frankly, it’s time for a shake-up, would you?
If you want object-oriented shell, use a LISP or Python interpreter. If you want an open system shell, use a text-based one. It speaks the only language that everybody speaks.
While the arguments that Java (and I’d assume .Net) aren’t as bloated as many people think they are, I too question the choice of using C#. I’m afraid that the additional VM start-up time maybe be a real PITA. I replaced NotePAd with JEdit which ran fine, but the amount of time it took to start up just to edit a file was a bit much when I just wanted to quickly check a log file.
However, it should be able to be ported over to C++ when they are done.
C# is one of the more elegant languages out there nowadays, when it comes to syntax it easily goes head to head with stuff like ruby and python, while rolling with a fast interpreter and one of the best APIs I have ever worked with.
The reason guys like miguel try to port it is that the closest thing linux has to something like it is java, and java is falling further and further behind as the years go by. Most serious linux development is done in either C, which was a great language, but at this point is kind of dated, and C++, which has always sort of been a mess.