Microsoft PowerShell RC1

rst+ack writes "Microsoft has released RC1 version of PowerShell the .NET-based shell with perl-like syntax previously known as Monad or MSH. PowerShell (PS) has been covered a few times on Slashdot. Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables. Easy access to .NET classes allows users to create quite advanced solutions in short time. PS won't be shipped with Vista or Windows Server 2007 but it will debut with Exchange 12."

can you?

[killjoe]

Can you resize the window and copy and paste easily into the windows. If so it's already 10 times better then CMD.EXE.

Re:can you?

[Vicegrip]

You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste. I use 132X9999. Turn on Quick Edit Mode for right-click paste actions. And, if you want, you can also drag a folder from Explorer into the window to copy-paste the path to the command line.

Re:can you?

[Otter]

OMG, bless you! (For those who don't understand what "check the properties of the window" means, right-click on the title bar.) I see you can drag files to the command line as well, not just directories.

To resume complaining about Microsoft, though -- perhaps they could include a help button or any other visual cue that there's more to the app than a window with a cursor? It doesn't have to be Clippy ("It looks like you're trying to use Unix commands out of habit!") but I wouldn't mind having the cat scratc

Re:can you?

[interiot]

Be sure to turn on tab-completion [nada.kth.se] while you're at it (it's not the best tab completion in the world, but it's better than nothing)

Re:can you?

[Otter]

That's working already. (Just as well, as I don't have permission for that registry change.) Maybe it's on by default in XP (the link refers to W2K) or maybe our company build has it on.

I actually like the sequential tab completion, at least when there are only a few options. My ideal would probably be the MS-style completion for a configurable number of choices, at which point it spills over to bash's tab-*beep*-type-tab-*beep*-type-tab behavior.

Re:can you?

[pla]

Turn on Quick Edit Mode for right-click paste actions.

Holy crap... Since I resigned myself to using XP at work, I have so wanted a way to get the command prompt to use the Win2k style of cutting and pasting.

And you've just provided it.

Bless you! If I had mod points, and you hadn't already hit "5"... Well, you get the idea.

Re:can you?

[drinkypoo]

Now if only the window could be made transparent, I'd have everything I want. Or close enough.

Re:can you?

[Excelsior]

You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste.

Increasing the buffer size still doesn't let you resize the window horizontally, although it does allow you to increase the size vertically. It's a fixed width window, which really stinks.

Re:can you?

[nmb3000]

Increasing the buffer size still doesn't let you resize the window horizontally

True, but you can change the maximum window width as well. Change the buffer and window widths from 80 chars to something like 120 to get a wider window. You can resize it to make it smaller, though you get scrollbars along the bottom of the window.

Not quite as nice as a *term window, but then Windows doesn't revolve around a terminal quite like *nix does.

Re:can you?

[forkazoo]

You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste.

Increasing the buffer size still doesn't let you resize the window horizontally, although it does allow you to increase the size vertically. It's a fixed width window, which really stinks.

It certainly isn't what it should be... But, if you go to properties, and go to the layout tab, then change *both* the horizontal buffer size and the the horizontal window size, it works fine. It's just buried on the third tab of the not-very-obvious properties window -- don't confuse it with the buffer size setting on the first tab, as this is unrelated.

Now, why in the name of god they don't just let you resize it with the mouse like every other Windows window, and every other terminal emulator like kterm/gterm... I have no god damned idea. But, it is there, pointlessly buried. Third tab of the non-obvious properties window, where you have to change two different settings by hand. People keep asking me why I don't prefer Windows. They keep insisting, "Isn't Windows easier to use?" Egad.

Quick resize

[Craig Davison]

For 90 cols x 60 lines, try

mode 90,60

Re:can you?

[Fareq]

while we're giving out CMD.EXE tips, try this:

enter a few commands
then press F7 for surprising results

Re:can you?

[Library Spoff]

Not much, it's a built in flight sim.
You can get similair functionality in Linux by installing FlightGear...

Re:can you?

[eMartin]

I haven't tried this release yet, but the last one, seemed to run in the same command prompt window, so all GUI functions were the same.

One nifty feature though, is that you no longer have to type the drive letter first to change to a directory on it.

In other words cyou can be in "c:\foo", and just type "cd d:\bar". You used to have to type "d:" and then "cd d:\bar".

Re:can you?

[bheer]

> One nifty feature though, is that you no longer have to type the drive letter first to change to a directory on it.

You can do that in cmd.exe too--

C:\Foo> cd /d D:\Bar
D:\Bar>

Re:can you?

[Opportunist]

Now THAT's a reason to upgrade...

Re:can you?

[cnettel]

Not sure what kind of resizing you are not able to do right now, but anyway the console is independent of what you run in it. It's like asking whether bash allows console window transparency in X.

Re:can you?

[Z34107]

You *can* copy and paste into cmd.exe. You right-click on the window and hit "paste."

Seriously, Linux users are supposed to be smart. ^_^

Re:can you?

[Opportunist]

Not only that, but you can do it in THREE DEEE!

Beats me why this should offer any benefit, but you can do it in THREE DEEE!

Re:can you?

[moro_666]

i a gree about the powervirus part. since microsoft has quite a bad backlog on security in the last ... emm .. many years, it's quite unlikely that this would bulletproof.

  but hey, it's at least it's the first three-dee virus platform :)

Text

[pete-classic]

Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables.

Why would you want to use an arbitrary, difficult to debug format like text when you could use .NET objects?!

-Peter

Re:Text

[cp.tar]

Currently reading: CLASH - Common Lisp As SHell.

Objects? We don't need no stinkin' objects!

Re:Text

[nuzak]

> Why would you want to use an arbitrary, difficult to debug format like text when you could use .NET objects?!

Maybe so we don't have to parse and re-parse and re-re-re-parse the damn text every time. To say nothing of data that's nested. Of course we could all just use XML and YAML, we just have to rewrite every app to serialize and unserialize these grotesque formats.

Frankly I don't see the need to justify the addition of functionality for people who do nothing but bitch about how real problems don't

Re:Text

[ookaze]

Maybe so we don't have to parse and re-parse and re-re-re-parse the damn text every time. To say nothing of data that's nested. Of course we could all just use XML and YAML, we just have to rewrite every app to serialize and unserialize these grotesque formats.

Do you understand that the shell is suited for system administrators and not for programmers ?
Well, programmers can use it too, that's a powerful feature, not a drawback.
System admin don't need to parse and reparse and re-re-reparse anything.
No BS abo

Re:Text

[RovingSlug]

Am I the only person that thinks piping objects between processes instead of an raw byte stream sounds very, very awesome?

I do a lot of bash and perl scripting and am very good at it. The freedom in transformation that perl gives over plain text is huge.

Extending that data to objects opens up a whole new world of capability in the same way, say, perl and regular expressions opened up whole new capability for munging data. Mmmm... munging objects.

Absolutely, totally cool. Don't be a Microsoft hater just b

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Text

[powerlord]

Well ... to take the position of "Devil's Advocate" for a minute, if they just extended bash to have C# scripting, then you'd have lots of people on this forum yelling how they are perverting the standard and that this is just aploy for them to embrace and extend the existing shell language.

Look at it from MS's perspective:
1) They know they need a shell like language to handle sys admin type functions.
2) They've just put a lot of effort into .Net
3) Most of the MS Admins out there believe VB is the tool of choice.

Given those suppositions (feel free to argue about their reality, but remember that I'm discussing it from MS's viewpoint), a scripting language that fullfills (1), takes advantage of (2) and leverages (3) seems like a no brainer, even for them.

Of course, considering that there are .Net bindings for Perl, that may be an even better choice for a scripting language.

Re:Text

[tomstdenis]

My problem is how blatantly incompatible they do everything.

Like I can use BSD or Linux or MacOS and for the most part the shell is compatible [they all have their own takes on shell].

Then you move to Windows and nothing is similar. They purposefully [for instance] use the wrong direction on the slashes to make things incompatible. That's the level of stupidity they stoop to.

There is no reason why they couldn't embed C# support [or generically .NET] within bash or tcsh or whatever. That way you could sti

Re:Text

[SpryGuy]

For the record, MS didn't choose the slash direction (I believe that came from CP/M which grew into the original DOS that MS bought and labeled MS-DOS). It's a legacy thing.

Additionally, I've used MKS Toolkit and other such add-on utilities to get completely compatable scripting, shells, and utilities across Unix, WinNT/2k/XP, etc.

Re:Text

[Octorian]

Yeah, VMS uses "/" for command line switches. Of course it does directories as "[foo.bar]" instead of "\foo\bar" or "/foo/bar", and when looking at a directory listing, directories show up like files with a ".dir" extension. The whole way VMS handles directories and files would probably confuse the heck out of DOS or UNIX users to some extent.

But I also think VMS and Microsoft have more of a connection in developer-land than UNIX and Microsoft, and it does sometimes show.

Re:Text

[cnettel]

Forward slashes has been supported in Windows (and DOS, actually) for ages. Back in 1981, there was certainly no universal "/" standard. DOS didn't go for cloning UNIX badly, it tried to emulate CP/M. / was already used as the command option char (among other things) when directories were introduced for real in DOS 2.0. The Mac did use : in all paths all the way up to MacOS 9. I know that this was only an example, but everything is not *NIX. That was definitely the case during the formative years for the up

Re:Text

[shmlco]

"My problem is how blatantly incompatible they do everything."

And his point was that, within the Windows environment, they ARE compatible, staying with their existing libraries, tools, and languages. Given that perspective, importing yet another language and toolset from Unix would be the incompatibility.

Why does the entire world have to look like a scripting language from an OS designed four decades ago?

Re:Text

[Billly Gates]

"Why does the entire world have to look like a scripting language from an OS designed four decades ago?"

Because computers input/output information just like they did decades ago. Unix is simple in the sense that everything can input and output data via text streams. Even the drivers in /dev and operating system internals in /proc can both recieve and output data via text from the shell!

Windows is great for grandma, but in an enterprise server room or for a power user its insufficient.

Why can't you manipulate the data inside the computer as easy as you could with unix? Why do I have to know x,y cordinate to click mouse buttons when running batch jobs for Windows programs?

PowerShell is a great idea and its about damn time. Since Windows uses objects it makes sense to use them as arguments as well as text and the WMI which reminds me of sysctrl and /proc in unix.

Its really all the same to me and just another implementation of the shell from unix.

Re:Text

[Octorian]

Just remember that "/proc" only contains process table information in real UNIX. The only OS I'm aware of where it contains everything one could possible care about in the kernel is Linux.

Also, "/proc" is rapidly being deprecated. Heck, on the *BSDs, it is mostly now a totally optional feature. MacOSX doesn't even have "/proc" at all. Solaris still has it, but I wonder how long. (since there are system/kernel calls that utilities can make to get at all that information anyways, and I've heard there are

Why?!?

[A nonymous Coward]

Why does the entire world have to look like a scripting language from an OS designed four decades ago?

Wheels -- thousands of years old. Still work.

Fire -- hundres of thousands of years under human control -- still works.

And you -- still typing after all these years, over a hundred now, since the invention of the keyboard. Still using fonts, for pete's sake, on graphical displays, invented before UNIX, along with mice, still using silicon (60 years old) and rust (thousands of years old) and electricity, back before Mr Franklin's experiments with kites 250 years ago, still using bits for storage as characters, processed by computer instructions, over 50 years old. Why haven't you graduated to something modern?

Re:Text

[Tim C]

They purposefully [for instance] use the wrong direction on the slashes to make things incompatible. That's the level of stupidity they stoop to.

When MS-DOS was first written, there was no such thing as directories. Everything lived in the root, and there was no need for path names or path separators. It quickly became necessary to pass arguments to commands, and the natural way to do this was to distinguish them from paramters by pre-pending a character. MS chose to use /.

Time passed, and directories were invented. People started to use / as a path separator, in similar fashion to how references are built up - eg major part/minor part/whatever/etc, say "57b/6". MS obviously had to support directory trees, but didn't want to break backward compatibility (something they are loathe to do to this day), and so could not use /. Thus, they went with the next nearest thing, \.

Alternatively, perhaps you're right, and they're petty and stupid enough to shoot themselves in the foot by making themselves incompatible with every competing product at a time when they had little or no compelling advantage.

Incidentally, try using / in a path in the address bar of Windows Explorer in a modern Windows (eg >= 2k). You might be surprised.

There is no reason why they couldn't embed C# support [or generically .NET] within bash or tcsh or whatever. That way you could still use the familiar but then extend into .NET crap if you wanted to.

What familiar? This isn't aimed at Unix admins, this is aimed at Windows admins, and most of them are going to be much more familiar with cmd.exe than with bash, or ksh, or ash, or tsh, zsh or any other of the myriad, subtly-incompatible *nix shells.

Re:Text

[boa13]

If I recall correctly they wrote the first MS-DOS manuals using troff/nroff on their own flavor of Unix, so they definitely knew what Unix was, what directories were, and how they were separated on major OS available at the time.

Re:Text

[tomstdenis]

And of course there is one true way(tm) of doing everything. Computing obviously reached its peak during the mid 80s and we should never ever do anything different because, you know, it'd upset the Unix geeks and you know how bad they can be when upset.

You say that but the only reason people like me like the "oss way" is that it's just that, open. If Larry decides to take a dive off the sanity train I can stick with the current copy of Perl. I have the right to use the code and furthermore distribute it.

I

Re:Text

[tomstdenis]

Tom uses Perl 5. :-)

That's my point exactly though. Larry is free to turn Perl into whatever he wants. The code is freely accessible. I can keep giving Perl 5.xx to my customers and not care what 6.xx does.

Furthermore, if I'm so inclined [I'm not... but] I can fix and add to Perl 5.xx if Larry [and the others] decide to abandon it.

Whereas in the MSFT world you're basically fucked. Reported bugs [especially in IE] often go unattended for long periods of time [CWS virus anyone?] and newer versions are oft

Re:Text

[shaitand]

"Well ... to take the position of "Devil's Advocate" for a minute, if they just extended bash to have C# scripting, then you'd have lots of people on this forum yelling how they are perverting the standard and that this is just aploy for them to embrace and extend the existing shell language."

They could *gasp* go prepare a draft for an extension to the standard and forfeit patent rights to related tech etc, and then formally propose an extension to the standard. Standards can be changed and extended you kno

Re:Text

[PsychicX]

Prepare yourself, this may come as a shock...It supports text based communication. Amongst the vast array of .NET objects is the ever popular System.String, which is of course an object representing plain text. Pipe it to a program and guess what happens? That's right, the .NET part is stripped away and the plain old text is sent to the app.

Microsoft gets it just fine. They get that *nix's text based communication is a crude and outdated way of doing things, and they provide a vastly more powerful interface, while keeping the old ones perfectly intact. I've been using MSH for several months now, and I'm amazed at how much more powerful it is than bash (which was previously a god in my eyes).

Re:Text

[smittyoneeach]

crude and outdated

Easily the oddest spelling of "simple and effective" I've ever seen.

Or, to thug Rob http://landley.net/ [landley.net]'s sig,

"Never bet against the cheap plastic solution."

Redmond's non-grasp of the wisdom of that observation is simply...titanic...

Re:Text

[projecto2501]

Our cheif weapon is strings, strings and objects. Our TWO weapons are strings, objects, and JIT bite code.

"Amongst the vast array of .NET objects is the ever popular System.String,....."

Nobody expects the command line!

Re:Text

[tomstdenis]

-1, flamebait.

Bash is extensible. You can easily embedded perl or other scripting languages in it. So if you don't like it's language you can mix and match.

I'm certain tcsh, ksh and the others have similar functionality.

Tom

Re:Text

[CastrTroy]

Looks to me like they made everything take 6 times as long to enter. All the commands are longer. That's what I love about unix, commands are as short as possible. Who cares if they are cryptic. Only people who really know how to use computers are going to use these tools anyway, and these people can cope with learning what ls,grep,cat,cp,rm, and all those other commands do.

Re:Text

[stikves]

Well I happen to have installed the thing, and tried "get-help *" to list all commands available. To my surprise, commands do have short aliases, some in the UNIX form!

Here are some of the commands available:

sleep, sort, tee, where, cat, cd, clear, cp, kill, ls
mount, mv, popd, ps, pushd, pwd, rm, rmdir, echo
cls, chdir, erase, move, rd

So please check first before asuming anything :)

The relevant quote...

[joe_bruin]

Ahem:

Those who do not understand Unix are condemned to reinvent it, poorly.

Re:The relevant quote...

[bod1988]

I belive they have. It's called linux.

Linux is posix

[CarpetShark]

No, linux is an implementation of Unix, not a reinvention of it. It's POSIX-compliant. Windows is still fumbling around with basic lessons which were learned by unix professionals years ago. Nothing different than you'd expect from an OS designed for home computers really.

As for monad/powershell... it's the same story. Instead of having the shell of your choice (bash,csh,zsh,python...) with the programming language of your choice (bash,perl,python,C++...) they're still trying to force a vision on people

Re:Linux is posix

[DaHat]

Linux is POSIX-compliant? No it's not... it implements a number of things from the standard but is by no means compliant with it.

If you are going to claim that the Linux implementation makes it compliant than you should extend a similar courtesy to Microsoft's POSIX implementations.

Both have some, but no where near all.

Re:The relevant quote...

[moosesocks]

How quickly we forget history [wikipedia.org].

Microsoft did Unix back in the 80s, and used it internally well into the 90s.

I would trust Microsoft's Unix knowledge just as well as I'd trust Apple's unix knowledge in the late 90s --- and look at the runaway success that OS X has been.

Don't judge a book by its cover. I'm not the biggest fan of Microsoft, but I'll concede that they've had a number of fantastic successes to their name. Powershell sounds quite interesting and innovative from what I hear -- actually one of the

Re:The relevant quote...

[PhrostyMcByte]

I've used MSH on and off for the past 2 years or so, and I can attest to it being powerful. I'm not a big bash scripter but this sure makes some things easier than what I've experienced in Linux shells.

The big thing is- who wants to wait 4-5 seconds for their shell to launch? And this is in 64-bit with 2 gigs of RAM and MSH ngened (ngen == cache of pre-JITed .NET code). What used to take a split second can now easily take orders of magnitude longer than the script itself takes to run. Plus, it runs inside the old cmd.exe - this means we're still stuck in a non-Unicode world. Good luck trying to run some quick database queries in non-ascii!

It's an admirable attempt but I think it's far too slow for normal use- until they fix that I can't imagine it picking up much of a following.

Re:The relevant quote...

[RupW]

Plus, it runs inside the old cmd.exe - this means we're still stuck in a non-Unicode world. Good luck trying to run some quick database queries in non-ascii!

Jeffrey Snover, chief architect, acknowledges this on the old blog [msdn.com]

We all share your frustration with the existing console. Remember that MSH.EXE is just our implementation of a UI for MONAD and that other people can provide them as well. I refer you to Karl Prosser's http://www.karlprosser.com/coder/?cat=8 [karlprosser.com] for a very cool UI.

Jeffrey Snover

(the old bl

Re:The relevant quote...

[shaitand]

Last I checked *nix is still winning ;)

How long will it take for them to create a CPAN?

[Scareduck]

Probably never, would be my guess, but one of the things I find annoying is how much reinvention-of-the-wheel Microsoft gets away with and yet continues to make the ridiculous claim that they're innovating, when in fact they're merely catching up. Bill Gates, welcome to 1994.

Re:How long will it take for them to create a CPAN

[x0n]

RTFM mate. This is not reinventing the wheel. It's adding a few more spokes, better tires and tougher rubber.

Re:How long will it take for them to create a CPAN

[ichigo 2.0]

Except the spokes are perpendicular to the old ones, the tires are on the inside and the rubber melts at high speeds.

but but but

[Austerity Empowers]

We WANT Linux/Unix shells...they work just great, and have lots of tool support...and have lots of good documentation...and have 20+ years of abuse.

Re:but but but

[x0n]

We WANT Linux/Unix shells...they work just great, and have lots of tool support...and have lots of good documentation...and have 20+ years of abuse.

Well, what's stopping you? install one [cygwin.com].

- Oisin

Re:but but but

[sedyn]

And 20 years ago, people thought GUIs were a toy. They liked shells, and they'd state similar reasons to yours.

I'm willing to give MS the benefit of the doubt here. They may have come up with a good idea (then again it could be terrible). I don't know if I'll ever use it (I banished Windows), but if I do I'll rate it without bias.

Should I give my, I'm not an MS shill disclaimer now?

Is that like PowerGlove?

[Orrin Bloquy]

If so, sign me and Fred Savage up!

i don't get it.

[moochfish]

Is it just me or does it seem insanely odd that a "shell" for an OS is a) shipped seperately and b) doesn't use text as a native data type? Maybe I'm stuck in the "past," but I always saw the shell as the barebones method for a user interact with an OS. Either this really is cutting edge (object data types) or this is just a hyped-up .NET application that is designed to *look like* the shell.

Re:i don't get it.

[pimpimpim]

not only shipped separately, but bundled with the Exchange mail server only! I guess it comes in handy to move mail databases around, but then again, maybe you need heavier stuff for that. It just doesn't make too much sense.

Furthermore, what I do with shell is, for example: call a program, catch the output, read in the 3rd column, print that combined some command to the shell again. This is easy when you work with text and you don't have to worry about the variable type of the 3rd column (be it a number,

Re:i don't get it.

[Chokolad]

> I think you will get in big trouble if all this data has to fit into a .NET datatype, you'll need a lot of coding around (string to filename, integer to filename, etc etc) to get it working, which is not what shell scripting is about!!! I will write a real program if I want to do something tidy like that, my shell script is there to solve a problem quick 'n dirty, thank you very much!

This exact scenario is actually simpler in Powershell - check this blog entry
http://blogs.msdn.com/powershell/archive/20 [msdn.com]

Re:i don't get it.

[ObsessiveMathsFreak]

Windows has a different culture to *nix. On *nix, most basic management software is either FOSS, or comes packed with the OS. On Windows systems, you pay for everything.

Everything.

Except IE.

Want file conversion software? Pay for it. Want interface software? Pay for it? Want ssh? Pay for it. Want to do something that is taken for granted in *nix systems and can be done by three different programs running on the system by default? Pay for it.

Let's face it, you can't get the functionality of pico on a windows

Re:i don't get it.

[Tumbleweed]

On Windows systems, you pay for everything. Everything. Except IE.

I guarantee you, I've paid and paid for IE.

And all I got was this lousy CSS support. *sigh*

Re:i don't get it.

[swissmonkey]

Given that 95% of the free tools available on Linux are available on Windows, me think that you've no idea what you're talking about.

On XBox Power platform? Passing Text Arrays?

[expro]

I wonder if the trademark works. They will probably have to call it Power Microsoft Shell. People will likely want to have Unix-like piping of textual results. Does this mean a Text array gets instantiated, or is it a stream object?

More like WMIScript

[Anonymous Coward]

Seriously. Look at the sample scripts [microsoft.com]. Every last one of them looks like this:

$strComputer = "."
 
$colItems = get-wmiobject -class "Win32_UTCTime" -namespace "root\CIMV2" `
-computername $strComputer
 
foreach ($objItem in $colItems) {
      write-host "Day: " $objItem.Day
      write-host "Day Of Week: " $objItem.DayOfWeek
      write-host "Hour: " $objItem.Hour
      write-host "Milliseconds: " $objItem.Milliseconds
      write-host "Minute: " $objItem.Minute
      write-host "Month: " $objItem.Month
      write-host "Quarter: " $objItem.Quarter
      write-host "Second: " $objItem.Second
      write-host "Week In Month: " $objItem.WeekInMonth
      write-host "Year: " $objItem.Year
      write-host
}

So, we can query the Windows Management Interface, and we can write it to the console. Awesome.

Guys, next time, think about making it do something before you put out a release candidate.

Re:More like WMIScript

[Anonymous Coward]

Unfortunately a lot of the examples on ScriptCenter are direct translations of VBScript examples. This is good in the sense that it shows how a VBScript user can migrate stuff to PowerShell. It's not, however, a good illustration of how PowerShell works. The above script can simply be written as

get-wmiobject Win32_UTCTime

WMI is one of the reasons we needed an object-based shell - it presents Window management information as a collection of objects. Writing code to render those objects to strings and then parse them back into objects is not realistic. We needed a shell that could deal with them directly.

Bruce Payette
PowerShell Technical Lead
Microsoft

Re:More like WMIScript

[YeeHaW_Jelte]

I can't believe no one picked up on this comment. Mr Payette here is giving us interesting insight into the reasons for the object-orientatedness of the shell.

As I understand it, the difference between PowerShell and your typical Unix shell is that the Unix OS is built around the shell and PowerShell is built around the OS.

As text exchange of data is the de facto way of piping data between applications in a unix system and the shell has long been the de facto way of interacting with the OS and the applications running on it most applications and the OS itself have been built to interact very well with the shell.

However, on windows, which hasn't been built around the shell and which presents objects as the standard way to share data, they had the choice of either
a: adding functionality to all applications in order to allow it to interact in a text-based way with cmd.exe, which is rediculous because of the vast number of applications already out.
OR
b: writing a shell built to integrate with the OS and the objects it uses to exchange data, which they did with PowerShell.

Basically, this seems a sound design decision which probably has it drawbacks (necessity for data type handling & such ) but seems like a good match for winOS'es. An object orientated shell would probably not work very well with a unix OS, if only for the fact that (most?) unixes are written in C, which does not do objects at all.

Seems like a good solution for windows systems, too bad it isn't (won't be?) included with the OS by default. It might make windows a better place to live for all us CLI types, and it can't possibly be worse than cmd.exe, can it?

Re:More like WMIScript

[tgv]

Unix is not built around the shell. The shell is just a normal executable (program, software, ice, whatever you call it) that uses Unix system calls to become a command interface.

The Unix shell has no knowledge of what the other executables or scripts that you execute with it do and the OS doesn't require text to be passed between programs. The unix philosophy is that everything is a stream of bytes and programs can do with them whatever they want.

The advantage of having a program output text rather than so

Re:More like WMIScript

[HawkingMattress]

If that's the case, the PowerShell is going to be somewhat inconsistent and tricky to deal with for people who are used to the (IMHO simple and elegant) idea that "ls > file; wc file" is the same as "ls | wc".

IIRC there is a text serializer which you can use with if all you want is basic text output. so ls | totext | wc would do the same as ls |wc on unix. And if they did things right (didn't tried monad myself, just read some articles about it), they'd have the "commands" have default input and ouput f

See! they admitted it!

[brightloudnoise]

Windows PowerS hell

I knew it all along!

Re:See! they admitted it!

[Anonymous Coward]

If that was true, hell would be freezing over constantly and therefore we'd all be getting laid on a daily basis.

Clippy?

[MightyMait]

What I want to know: does it come with a text version of Clippy?

Strains the definition of "shell", kinda

[Anonymous Coward]

So: You want a shell-like environment that lets you type in commands to operate on objects representing files, directories, etc.

Great! Install python*, install the file packages, open the interactive interpreter... you're done.

Why bother waiting for this MONAD thing? It looks like all MONAD offers over any other interactively interpreted programming language right now is that it is compatible with the C# object model. Which, y'know, on the one hand, the UNIX "glue" platforms (python, perl, ruby, kde, gtk) could totally benefit from a unified object model that would allow you to construct an object in a GTK+ application, pass it to a perl script, pipe it to a ruby app, etc. But, y'know, on the other hand, python on windows supports the CLR/C# object model as well... and it's available now.

* Or ruby.

What about the applications?

[miffo.swe]

The thing in *nix is that most applications support the shell. They are built for piping stuff in any possible way. Are the Windows applications going to be built with the shell in mind or is this going to be yet another cmd.exe where you have to build your own stuff to do what you want instead of like *nix where you just pipe at your hearts content.

I have also a hard time imaging using objects being easier to understand for normal admins and users.

Also, when exactly did the shell stop to suck and begin to be a good feture? The same second Microsoft made their own version?

I've tried PowerShell (formerly Monad)

[eman1961]

Shells are often used for managing systems and networks. I think that PowerShell will do an adequate job at this, although it seemed to be more complicated than necessary to me.

Unix shell scripts are also incredibly good at manipulating text files, using awk, grep, sed, cut, etc. I tried to do such a task with PowerShell and found it wanting. I revered to Windows Services for Unix (basically the Korn shell).

For those who don't know, a monad is a notion in functional programming languages that is a way to structure computations in terms of values and sequences of computations using those values. Monads allow the programmer to build computations using sequential building blocks, which can themselves be sequences of computations. This is not dissimilar to how PowerShell works, but really, I when manipulating text files, I don't want to be dealing with functional programming language abstractions.

Re:I've tried PowerShell (formerly Monad)

[DrAegoon]

I always loved the old "Monad" name but I guess they changed it since no one got the joke. According to this page (second answer) [microsoft.com] the inspiration came from the 17th century philosopher Gottfried Leibniz. Leibniz proposed the concept of a Monad as the fundamental particle of the mental realm much as the atom is the fundamental particle of the physical realm.

Monads are supposedly self contained and closed off from any outside input. This leads to the joke as I understood it. In describing the concept in his

Downloading

[Lando]

Doesn't appear to be a way to get a copy to look at unless you have Passport which seems to require a hotmail account. I don't have time to read a couple of dozen licensing agreements atm and it looks like if I register I'm basically signing a non-compete license with Microsoft. Not really a term that I am willing to agree to. Has anyone gone through the contracts?

Re:Downloading

[cybereal]

It takes five minutes to setup a passport account associated with any arbitrary email address and thus far has generated absolutely zero spam to my email account. You can also sign-up with a "Limited" passport account, which means, you can sign up with no association with any actual email address whatsoever. You end up creating a fake @passport.com address for signing in.

The contracts are not any different than what you would agree to with Google, Yahoo, or any other online service provider.

Furthermore, with only accepting the passport license, it's a bit shorter than hotmail's. Try reading it yourself. The TOS is actually very short and easy to read if you're not illiterate: https://accountservices.passport.net/PPTOU.srf?x=4 .0.5610.0&cbalt=www&vv=400&lc=1033 [passport.net]

And the point is?

[thetoastman]

First of all, I would have to upgrade from Windows/2000 Professional to Windows/XP Professional. Since this costs money, I'm not terribly interested. My system has enough trouble running all the stuff I run now (2 databases, a web server, an application server, a development environment, etc. etc.). More operating system overhead is the last thing I'm interested in.

Second of all, I get to write scripts in another language that's not portable across all platforms. I've never worked in a monolithic environment, and I probably never will. Cross-platform tools are a requirement.

Third, I can do a lot of administrative programming for Windows in Perl. I imagine python and ruby have similar hooks (haven't checked). For personal productivity I run Cygwin's version of bash on this machine when I'm running Windows, and bash when I'm running Linux. Different people may want different interactive tools. Fortunately there are several cross-platform choices.

Finally, while I've heard about all these productivity gains with C# and .NET, I've not experienced it. I have .NET, C#, and Visual C++ .NET on the Windows side of my environment. What I've seen is that Microsoft makes a credible IDE. The IDE makes simple things easy, and complex things ridiculous. Transferring skills learned in the Microsoft world to any other environment is difficult at best, and pointless for the most part.

Oh - never mind - that's Microsoft's point.

Come kick the tires

[jsnover]

I encourage you all to come kick the tires and find out what PowerShell really does/does not do. I think you'll be pleasantly surprised by its power and simplicity and might even like it. Many of us on the team have a deep background in UNIX and brought that into our work. Even if you don't like what we've done, trying it out will allow you to know enough to throw your rocks accurately. :-)

http://www.microsoft.com/downloads/details.aspx?Fa milyId=2B0BBFCD-0797-4083-A817-5E6A054A85C9&displa ylang=en [microsoft.com]

If you'd like to learn more, you can read our team blog at:
http://blogs.msdn.com/PowerShell [msdn.com]

Enjoy!
Jeffrey Snover
PowerShell Architect

Re:Come kick the tires

[Aladrin]

Okay sparky, here's the problem:

Registration Required for This Download

Okay, so I've got a passport account (please don't mod me down for this, I was young and stupid.) And yet, you can't sign in because passport is freaking out.

I have been DYING for a worthwhile shell in windows. I've been using rxvt and aterm and they just don't match up to a console-only or yakuake session in true linux. I would LOVE to try your stuff. But you have to MAKE IT AVAILABLE TO DOWNLOAD.

Re:Come kick the tires

[Westley]

I had this yesterday, too. I believe it's due to Windows Live changes. Try following the "log in with a different email address" link (or whatever it is - you'll know the one I mean), then use the same address again, and things may well be okay. I had to do the above and then start from the download page again, but I got in that time.

Jon

DIRECT DOWNLOAD LINK (no passpos)

[Anonymous Coward]

Windows PowerShell RC1 (for .NET Framework 2.0 RTM) x86

http://download.microsoft.com/download/e/8/c/e8ccf 14c-8009-43ad-b953-1b18609cf14c/PowerShell_i386.zi p [microsoft.com]

Re:DIRECT DOWNLOAD LINK (no passpos)

[Aladrin]

Oh, the hilarity. Using Linux I was able to sign into Passport where I was not able to on Windows.

Anyhow, here's the x64 link requested.

http://www.microsoft.com/downloads/info.aspx?na=90 &p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=4 A2D5ECB-0740-4AD5-98D3-EB236C3F37D9&u=http%3A%2F%2 Fdownload.microsoft.com%2Fdownload%2Fc%2F8%2Fe%2Fc 8e2b52a-d27c-447a-bd3f-73cf764beb26%2FPowerShell_a md64.zip [microsoft.com]

Re:Come kick the tires

[fade-in]

I hate to admit it, but from what I've seen of PowerShell I've really liked. I like the idea that the syntax for all commands is consistant, and enforced by the framework. No time spent retrofitting old commands to a new standard. Well, I guess you get that for free because you are now building everything from the ground up anyway.

Some of the object-oriented features are quite nifty, and I don't see any of the standard UNIX shells doing that anytime soon. But I guess I'd really have to get into it bef

Obviously designed by programmers for programmers

[RebornData]

Although I haven't played with it, I've read a bit about this shell, and there was something that bothered me about it, and I finally just put my finger on it: this thing was designed by programmers.

I know that the line between "programmer" and "system administrator" is often blurry. And the line between "shell" and "interactive script interpreter" is as well. But when you start requiring people to understand concepts like objects (which may seem like old hat to a programmer), you're already presuming a relatively sophisticated understanding that an "average user" has no grasp of. And the .Net libraries are vast and complex... looking at some of the sample msh scripts, I understand how a windows programmer would think they were an amazingly powerful simplification, but damn there's a lot I have to know to get basic things done.

Ye olde csh and sh are great because they provide a simple way to put programming logic around the set of operations users spend their entire day in and are already familiar with. The learning curve is very incremental: you can master the basic UNIX commands, and then start to add in variable subtitutions (!$ anyone?) and loops (foreach) and such as needed.

In other words, the jump from basic UNIX user knowledge to simple scripting is very small, because the scripting is presented in *exactly* the same context and using the syntax the user does day-to-day work in. But as a competant windows admin who doesn't know VB and hasn't written a line of .Net code in my life, I see almost nothing familar when I read .msh scripts. It appears to require an entirely new body of knowledge to do simple things, and bears little or no relationship to the interfaces and paradigms I use day to day. Yes, I know those interfaces are graphical. Seems to me there's bound to be some way to do it (or would be if there were any logic or consistency to the organization of the everyday administative interfaces in Microsoft's products).

Don't get me wrong... I understand that the goal of an intuitive scripting tool is in many ways at odds with providing a rich and powerful development environment that can complete with something like perl, but I had hoped there was something a little closer to "ground level" coming.

-R

Believe it or not....

[XMilkProject]

I know its hard to accept microsoft did something good, but as someone who has been using betas of this for months, I must say it is pretty darn slick.

Think of how great your linux environment is, becuase you can easily chain together applications that pass textual data between each other... This is the same idea, except we can now pass complex objects and custom data types as well.

To solve the problem of how to 'display' an object, each object type can have an xml file describing how to display it in a text environment.

REXX? AppleScript?

[mccalli]

In other words. An OOP shell.

I don't know, it sounds a lot more like the REXX and AppleScript way of doing things to me. An application exposes a dictionary of possible actions (rephrased in OO, an application object exposes methods) and passes the results to the next REXX or AppleScript-aware application.

Both REXX and AppleScript predate wide scale adoption of OO, so I might be off-base. It does sound very similar though, and personally I think there's room for both that approach and the classic Bourne shell-style approach.

Cheers,
Ian

Re:REXX? AppleScript?

[NutscrapeSucks]

MS already ships something exactly like REXX/AppleScript with Windows Script (usually VBScript). The main difference with "PowerShell" is that it's designed to be more of an interactive command language than a scripting/programming language.

Re:REXX? AppleScript?

[throx]

You're thinking about it the wrong way. It's OO in the sense of stdin and stdout, which are object streams and not character streams.

For example, "dir" returns a stream of objects which are of type "File". If you pipe that output into another command then it has the full file information available to it from the object stream, so can act on the file contents, file name, file type, file dates etc if it chooses. Another command "list-users" may output a stream of user objects. Something else may output a

Re:How much will it cost?

[cnettel]

It will be a general download to the OS as well. It's just that the admin scripts shipped with Exchange will rely on it.

Re:How much will it cost?

[cnettel]

I didn't :-)

Re:Vista: Includes Free RootKit!

[cnettel]

Hm, what kind of security do you expect in a shell? But, IIRC, you can run scripts under any .NET permission set, which means that you can emulate stricter permissions than the user you are running under (just like the Java VM does). I think there is also some code signing possible, but it's always a tradeoff, isn't it? It's not exactly like you want to log into some kind of stealth mode to just sign a script you have edited.

Re:Vista: Includes Free RootKit!

[amliebsch]

It's a legitimate question. The security of PSH is mainly two-pronged: first, as in every other console/shell, including cmd.exe, commands and scripts can only act with the permissions that the current user has. This is the standard *nix way of doing things, and it should be far more effective in Vista once proper LUA is finally well-implemented. The other prong is a combination of security features. First, there will be no default associated file type for PSH scripts, meaning that by default, it is not possible to double click a script file and have it run, like you currently can with .BAT files. You can always create an association, but the default behavior is to instatiate the shell first, then run the script with a command-line command. Second, by default, scripts in the current director must be explicitly invoked (equivalent to not having "./" in your PATH). Third, PSH will support code signing, so that scripts must be digitally signed by a trusted publisher. This can, of course, be yourself, because you can easily enough create a cert and trust your own certificate. But it would prevent a lot of trojan attacks.

Re:Kinda reminds me of Access

[cnettel]

Uh, it is a COMMAND SHELL? Of course it's text input based. They also claim that future graphical admin tools will render the equivalent commands in a text field, somewhat like what you describe. But this one certainly uses a text-based interface... The object-orientation is just about how commands interact with each other, especially when piping. Plain text piping between commands (note, not processes, the builtin commands are objects that will generally live in the same process as the shell itself) is a limited special case of this.

Comment removed

[account_deleted]

Comment removed based on user account deletion