Linked by Thom Holwerda on Mon 7th Apr 2008 20:38 UTC
.NET (dotGNU too) 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)."
Order by: Score:
Finally
by sukru on Mon 7th Apr 2008 21:18 UTC
sukru
Member since:
2006-11-19

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.

Reply Score: 11

Tile TK
by Flatland_Spider on Mon 7th Apr 2008 21:22 UTC
Flatland_Spider
Member since:
2006-09-01

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.

Reply Score: 3

RE: Tile TK
by WorknMan on Mon 7th Apr 2008 21:55 UTC in reply to "Tile TK"
WorknMan Member since:
2005-11-13

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.

Reply Score: 12

RE[2]: Tile TK
by superstoned on Tue 8th Apr 2008 05:37 UTC in reply to "RE: Tile TK"
superstoned Member since:
2005-07-07

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.

Reply Score: 2

RE[2]: Tile TK
by Earl Colby pottinger on Wed 9th Apr 2008 01:48 UTC in reply to "RE: Tile TK"
Earl Colby pottinger Member since:
2005-07-06

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.

Reply Score: 2

RE[3]: Tile TK
by fithisux on Wed 9th Apr 2008 02:12 UTC in reply to "RE[2]: Tile TK"
fithisux Member since:
2006-01-22

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.



Good for academics!!!

Reply Score: 2

Another project using .NET/MONO? A fail
by timofonic on Mon 7th Apr 2008 21:58 UTC
timofonic
Member since:
2006-01-26

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

Reply Score: 2

Nelson Member since:
2005-11-29

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.

Reply Score: 8

Beta Member since:
2005-07-06

…as we all know ECMA is completely independent.

Reply Score: 5

n4cer Member since:
2005-07-06

…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...

Reply Score: 2

Beta Member since:
2005-07-06

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....


Those are the same standards: they’ve only been PAS’ed by ISO.

Reply Score: 2

sbergman27 Member since:
2005-07-24

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

Reply Score: 2

whartung Member since:
2005-07-06

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...


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.

Reply Score: 3

sbergman27 Member since:
2005-07-24

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.

Reply Score: 3

hhas Member since:
2006-11-28

If I changed my login shell to /usr/bin/python and eschewed bash for a 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/

Reply Score: 2

sbergman27 Member since:
2005-07-24

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

Reply Score: 2

Terracotta Member since:
2005-08-15

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.

Reply Score: 2

hhas Member since:
2006-11-28

I don't understand why Pash when existing stuff like ZSH and the power of shell scripting.


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.

Reply Score: 9

colinwalters Member since:
2007-11-02

Hotwire is an attempt to superset Unix text-stream pipes with an object-oriented approach, currently using the Python runtime:
http://hotwire-shell.org

Reply Score: 5

apoclypse Member since:
2007-02-17

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.

Reply Score: 3

google_ninja Member since:
2006-02-05

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....

Reply Score: 4

sbergman27 Member since:
2005-07-24

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.

Reply Score: 3

google_ninja Member since:
2006-02-05

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.

Reply Score: 2

sbergman27 Member since:
2005-07-24

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

Reply Score: 2

hhas Member since:
2006-11-28

Mmmm, looks interesting. Will check it out.

Reply Score: 1

leos Member since:
2005-09-21

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.


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.

Reply Score: 6

google_ninja Member since:
2006-02-05

What you're saying is they're not buzzword compliant.


LMAO!

Shells are supposed to be quick and dirty. Powershell is a way overengineered solution to the problem of shell scripting


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.

Reply Score: 3

hhas Member since:
2006-11-28

What you're saying is they're not buzzword compliant.


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.

Shells are supposed to be quick and dirty.


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.

Reply Score: 3

sakeniwefu Member since:
2008-02-26

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.

Reply Score: 1

tux68 Member since:
2006-10-24

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.


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

Reply Score: 2

sakeniwefu Member since:
2008-02-26

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.

Reply Score: 2

tux68 Member since:
2006-10-24

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.


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.

Reply Score: 2

sakeniwefu Member since:
2008-02-26

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.

Reply Score: 2

siride Member since:
2006-01-02

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.

Reply Score: 7

CaptainPinko Member since:
2005-07-21

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.


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.

Reply Score: 4

google_ninja Member since:
2006-02-05

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.


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.

Reply Score: 6