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

Comments

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?

[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?

[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?

[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?

[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 scratch itself and chase butterflies while SAS runs...

Re:can you?

[interiot]

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

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.

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?

[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 :)

Re:can you?

[Library Spoff]

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

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

[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 still use the familiar but then extend into .NET crap if you wanted to.

Of course for MSFT the big differentiating "feature" they have is that they're not inter-compatible with others. I mean look at how they implemented IE.

Tom

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 really exist. You stick to piping text everywhere, no one's taking it away from you.

Anyway, it'll be cloned it within a month and then the slashdoterati will claim they invented it. Or maybe it'll run on Mono.

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

[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

[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

[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 because it's the popular thing to do.

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

[tiocsti]

That's just not the case, cp/m did not have subdirectories at all (neither did msdos till ver 2.x or so). Okay, sure you can make the argument that users are subdirectories, but they didnt have a / and users were always at the top level (you can have up to 16 users, the default one being user 0 and going up to user 15).

The reason microsoft used \ instead of / has to do with how dos and cpm (possibly borrowed from vms?) pass command line switches to programs, they used the / character, so to avoid confusion microsoft used \. I guess it could have been worse, they could have enclosed subdirs in a pair of braces like cd [mydir] and cd [-], but that's another story altogether.

Re:Text

[Philip K Dickhead]

"...Riotous!"
"...outlandish... offbeat and hilarious!"
"If you read only one comment this year, read this!"

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

[smittyoneeach]

crude and outdated

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

Or, to thug Rob http://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

[bheer]

> They purposefully [for instance] use the wrong direction on the slashes to make things incompatible.

Ironically, Powershell (ugh, I think I'll stick to Monad) accepts both \ and / as directory separator characters and uses - as the default switch indicator (/ is still accepted to make lives easier for people coming in from a DOS background)

> My problem is how blatantly incompatible they do everything.

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.

Or you could run cygwin on Windows. But I guess it's easier to kvetch.

Anyway -- It's their platform. Powershell is intended for admins running Exchange. Exchange's admin GUI will generate Powershell Commandlets that will let Windows admins package repetitive tasks in a non-programmy sort of way without taking away power and expressiveness from those who *want* to program. But of course, Microsoft should accept an external risk and go ahead and integrate Perl/Python/whatnot into its products because that'd make *you* happy. Who died and made you the Sultan of Brunei?

(As a side note, Microsoft internally has no trouble with Perl. The problem is that its customers (typically enterprises who buy Windows Servers) are quite clear that they want nothing to do with Perl-- primarily because of the CIO perception that Perl is write-only and that Perl code is essentially job-security for the admin that wrote it.)

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

[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]

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.

If MSFT takes [... :-)] a dive off the sanity train you're fucked. What, you gonna distribute older copies of Monad [say a version you liked] to your clients? I don't fucking think so.

That and yes, bash and the other shells have worked fine for decades. I can embed perl/python/etc scripts directly into a shell script for greater flexibility. Since perl has an 'exec' function I can even send it code or other data directly.

The MSFT way is just "different" but not because they want to do something that is fundamentally better. Just because it leverages their vertical market strategies in a push-pull positive influential manner!

Show me how, for instance, ASP or their other SSI incompatible technologies are fundaementally better than PHP or CGI via Perl.

Show me how their variations on the HTML standards are "better".

Show me how their take on the C and C++ languages is "better".

It's simple economics. If you can isolate your customers from your competition you rule them all. That's all that drives this level of "innovation". I mean if it was really about the technology then where is Monad for Linux? I mean is Monad actually integral to the Windows operating system? Similarly where is Office for Linux?

So people bitch "oh but there isn't $SERVICE in Linux" but I'd still point out the bulk majority of Office applications is just userspace crap. No reason why it can't work in other OSes.

If OpenOffice can run on a dozen platforms and it isn't written by the supposedly "best" people in the world [best being Microsoft] then clearly MSFT is missing something.

Tom

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

[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 security issues with "/proc")

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 :)

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 often ever so slightly incompatible with previous versions of the same tool.

If people really can't see MSFTs approach to "segment, divide and conquer" development then they really deserve what they get.

Tom

Re:Text

[TheUser0x58]

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

Im pretty sure the original UNIX had directories, a decade before MS-DOS was written.

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

[tyme]

TimC wrote:

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

There is just so much wrong with what you wrote that it is hard to know where to begin, it almost seems that you weren't even alive when these things happened:

• while MS-DOS 1.0 did not have an hierarchical file system (a file system with directories and sub-directories) the concept of directories most certainly existed at the time that MS-DOS 1.0 was released (around 1981 or 1982). Other operating systems, including Unix, had been using hierachical file system for at least a decade (Unix was invented around 1972 and had a hierarchical file system almost from day one). While hierarchical file systems were not common on personal computers of the era, they were far from unknown.
  

• The slash was not chosen as the option flag indicator by the makers of MS-DOS, it was adopted in order to be compatible with the dominant personal computer operating system of the day, CP/M, from which much of MS-DOS's design was originally cribbed. The use of the slash to indicate an option flag to a command in CP/M was taken, in turn, from the same custom used by operating systems from Digital Equipment Corporation (DEC), such as RT-11, RSX-11, TOPS-10 and, later, VMS. The use of the slash character to indicate an option flag was, therefore, a part of MS-DOS from its inception.
  

  Other aspects of MS-DOS were also taken from DEC OS's via CP/M: drive letters delimited by a colon, the 8.3 file name limit, file extensions and much of the original MS-DOS API are all carried over from CP/M and are in CP/M because they mirror similar features of DEC operating systems.
  

• When a hierarchical file system was introduced to MS-DOS with version 2.0 it was pretty clear, at the time, that Micorsoft was trying to turn MS-DOS into a Unix look-alike (the hierarchical file system was unixy, as were a number of new OS APIs, including a whole new set of handle-based file-I/O routines, as well as command I/O redirection and piping in the shell). Since the slash had already been used by the DEC-lovers for option flag indication, and since the new-guard at MS wanted stuff to look as unixy as possible, they settled on the next-best-thing to a slash: a backslash. In other words, the backslash was chosen, not for it's incompatability but because it was as compatible as possible without breaking backward compatability with MS-DOS 1.0 and CP/M.
  

In fact, the Microsoft folks had very little choice in the workings of MS-DOS 1.0: they bought it for a song from the original author and had to ship it almost immediately. They couldn't have changed the flat file system or the other CP/M-isms even if they had wanted to (they probably didn't want to, initially, since the CP/M 'compatability' was a selling point). To suggest, however, that any of this was done in innocent ignorance, or that any of these things were invented after the introduction of MS-DOS, is simply dishonest: all the concepts that Microsoft later incorporated into MS-DOS 2.0 were present in existing operating systems ten years earlier (1970-73) and were well known to anyone familiar with computers at the time (1981/82).

Re:Text

[gnud]

I don't know much about GNOME, but most of KDE (including KOffice) is scriptable via DCOP. DCOP can be used via the command line, or in several languages (python, ruby, perl, java, perhaps more). For building a program (yes, with a nice shiny gui) quickly and effectivly, use Kommander.

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 about nested data either.

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 really exist. You stick to piping text everywhere, no one's taking it away from you.

To add functionality, the basics should be there. Do you understand that the shell does not just pipe text ? It does far more than that, it is portable and even helps boot some OS, you know. And in this case, piping is one minor feature, environment and managing jobs is far more important.

Anyway, it'll be cloned it within a month and then the slashdoterati will claim they invented it. Or maybe it'll run on Mono.

And a troll to add credibility to your argument ... Pathetic.

Re:Text

[magetoo]

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

No, it's just that the rest of us got turned off by the first few pages of "but the console windows aren't transparent" and "backslash instead of slash for a pathname separator SUCKS!".

And modding all those posts off topic would drain the supply of mod points so quick the whole universe would disappear in a puff of division-by-zero, which is too bad.

Re:Text

[squiggleslash]

Yeah, me too. I don't know, but the last few days, Slashdot seems to have attracted more dumbness than usual.

What we have here is actually fascinating. It's an entirely new way of looking at the command line. It moves from the file based systems we've used since computing began, and instead looks at the high level programming and works within that framework. I think that's great, personally. If Microsoft could produce an operating system that eschews Win32/Win16/DOS et al completely and is pure .NET, with this as the shell, they would be producing something entirely radical and interesting at the same time, something that may well end up being several orders of magnitude more usable and useful than the Unix-based competition.

I'd have appreciated a good discussion about it. As it is, I guess I'll have to wait until John Siracuse does an article for Ars Technica on the subject, and I'm not certain he will.

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.

Re:The relevant quote...

[moosesocks]

How quickly we forget history.

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 few true 'innovations' to come out of MS in recent memory. I'll look forward to seeing how it works out.

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

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 for a very cool UI.

Jeffrey Snover

(the old blog's articles have been copied to the new PowerShell blog but the comments haven't.)

Re:The relevant quote...

[leonard_chung]

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!

The startup time is something we're aware of and are working to improve as we reach RTM. Our priorities thus far have been primarily around ensuring that the core functionality is correct and the shell experience is a high quality one. As we move forward, we will be tuning up the performance of the Windows PowerShell.

With that said, this is just initial startup of the shell in which you should get the worst hit prior to the prompt loading. If you close the shell thereafter and load it again, the shell should open promptly. Individual commands execute more quickly as well as passing objects does not require a performance sapping test output and reparse phase which is normally required in most shells.

If you have particular scenarios or issues with PowerShell performance, let us know at http://connect.microsoft.com/ (sign up for PowerShell under Available Programs)

Leonard Chung
Program Manager
Windows PowerShell

Is that like PowerGlove?

[Orrin Bloquy]

If so, sign me and Fred Savage up!

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?

[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 stream of some other type of object. etc.

From there, and some "glue" type commands which allow object transformation, property selection and taking of subsets of objects you can build up a fairly powerful command line that looks like a unix shell but is kinda different too when you think of all the metadata going between the commands.

Naturally, as every .NET object has a ToString() method, if the final output actually ends up on the console then ToString() is called and you get a result.

Kinda cool. Not sure if it will be more or less useful than the unix model though.

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, a filename, a date, an executable command). 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!

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 install without buying or downloading a third party piece of software. And FOSS software is hard to come by on windows, so you're left with the option of paying $15 for a program that reads id3 tags or has syntax highlighting. The danm OS doesn't even come with a compiler.

If you're working in windows, it means you've decided to pay good money for inferior versions of basic tools that come free on a *nix system. Hence, if PowerShell becomes popular, expect companies to repackage csh and bash variants for $500 a pop to Vista admins that have reached the limits of their $50 Powershell.

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/2006/04/2 5/583272.aspx

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?

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.

More like WMIScript

[Anonymous Coward]

Seriously. Look at the sample scripts. 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 some object structure, is that it's output can be trivially displayed (i.e., without further translation). So, if I type "ls" under Unix, I can read the actual file names.

The disadvantage is that information gets lost. E.g., "ls a*" displays file names next to each other, doesn't display the path name or other information. When you ask it to do so, its output becomes more complex to parse for other programs in the pipe.

It seems the PowerShell tries to overcome this problem by having "ls a*" (or "dir a*.*" :-) output objects instead of text and then doing the translating for you only at display time (correct me if I'm wrong). That way, when you pipe "ls a*" output into another program, that program has all information it needs about the files you were looking for.

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

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 formats, which would call specific serializers. So in this case, wc would default to text input, forcing the command in the left hand pipe to serialize its data to text unless a special parameter is supplied to wc. But i'm just speculating on this one.

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?

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.

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.

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.

- Oisin

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.

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?

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.

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) 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 Monadology Leibniz says, "Monads have no windows, through which anything could come in or go out," an appropriate quality for a command shell ;)

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 that will probably turn out to be fundamentally flawed in some way.

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:On XBox Power platform? Passing Text Arrays?

[weapon]

>They will probably have to call it Power Microsoft Shell.

Power Microsoft Shell - PMS, would this be a description of the shell's behavior?

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

Re:.Net rocks

[pandrijeczko]

There, I said it.

BASH shell-scripting kicks ass. So do PERL, Python, the Korn Shell, PHP and C (and it's derivatives). I know enough about all of them to use one or more of them to do most of the tasks I need to do in the timescale I need to do them.

I've never programmed anything in any Microsoft programming environment because I've never needed to - and it would take me far too long to learn their way of doing things from scratch rather than working with what I know.

However, I know a few MS-based programmers who managed to develop the tools they need to in .NET or whatever it is they use - I'm sorry, I'm not informed enough about MS programming environments to voice any more opinions about it.

Suffice it to say, they're happy and I'm happy.

So everything is right with the world.

End of story.

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.

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.

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

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

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

[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 before an OO shell became much of a *NEED*. Right now, it feels more like a "gee, that's kinda cool" sort of feature that I really don't much care for when performance is a bigger priority. I don't forsee PowerShell one-upping Bash in speed anytime soon, and that's not saying much to the folks who believe that Bash is already bloatware.

Does anyone besides me revel in the irony that MacOS and Windows now feature modern command-lines?

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

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:.Net rocks

[resonantblue]

I'm an avid Python, PHP, Perl, Ruby, and C# programmer.

Ok, those *nix languages are all fine (I particularly am fond of Python), but C# is definitely a very nice language. Give credit where credit is due.

I can tell you from personal experience that I haven't found development/debugging tools in any of those other languages that compare to Microsoft's.

And as for your comment about the learning curve, I totally don't get that. So you have no problem with the learning curve involved in learning Perl, Python, Korn, PHP, and C and yet you have a problem learning c#? Those languages don't even share the same libraries; at least with .NET you can switch from C# to C++ to J# and still use the same common libraries! And if you already know C, then learning C# is a piece of cake. Same for Java and J#. Your "learning curve" comment is totally unjustified as far as I'm concerned.

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.

Quick resize

[Craig Davison]

For 90 cols x 60 lines, try

mode 90,60

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

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

cygwin & rxvt

[kybred]

You might look into Cygwin and rxvt.

The other PowerShell

[PJC1]

Couldn't they have picked a different name? I've been using PowerShell on Linux for years now. It's a terminal emulator for X11 (like xterm) and is the first result on Google for the word PowerShell. Now a terminal emulator isn't exactly the same as a shell, but I could see some confusion occurring as a result.

The most important question

[Antimatter3009]

Can I use ls to get a file listing yet?

Good - need a change

[Ajehals]

Am I the only one here who has spent weeks of work time writing batch and vbscripts to automate operations on Wn2k Servers and networked Windows clients? If this works as advertised (and if I was still running Windows) Id use it.

Its a step in the right direction and anything that extends an admins ability to write effective scripts is a bonus. After all whilst it may have taken me a few days to write some of the more complex scripts that we used it would have taken longer to write an application in VB or C to do the same job.

(BASH is my shell of choice, its because I have an unhealthy obsession with grep...)
nb Not spell checking this post - its too early

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

Maybe we can learn something from that

[moria]

Virtually communication under Unix is text-based, no matter it's human-to-program or program-to-program. The CLI output/input is text based; the configuration file is text-based; the log is text-based. I think the reason is that most of the stuff is originally designed for human to read: the thing you pipe to another program is initially intended to be examined by human; the configuration and log is also built to allow a human to read, interpret and change them, manually. However, when this human-oriented (or geek-oriented) text is used to glue different programs, it means extra work to parse them. Thanks to awk and the standardization on standard programs like ps, so far, so good.

We actually have already seen troubles with this approach. How many programs have tried to override your xorg.conf/sources.list/sshd_config because they don't have a nice way to just insert a few records and gracefully remove it later? Wouldn't it be better if the configuration system provides API for other programs and, more importantly, scripts to interact with it and a GUI/CUI/curse for human to change it, just like what gconf2 has done?

Maybe it's time for us to put more OO-friendly stuff into UNIX. Apple/OPENSETP has been along the OO-based API road for like 10 years, and MS is trying essentially the same thing with .NET. It's true that we have a lot of OO goodies on UNIX like python and ruby. But the problem is that they are at a higher level, and therefore if you want a python program to interact with ruby, you have to dump your object into text and parse it back into object representation at the other end. It would be nice if we could have some lower-level object layer or simply standardize an object serialization scheme.

It's true that intercommunication with objects is more efficient and flexible for computer programs.

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?

Amazing Microsoft shell skillz!

[CrankyOldBastard]

If you look at http://blogs.msdn.com/powershell/archive/2006/04/2 5/583272.aspx you can see examples of why this PS is better than ksh. They seem to have deliberatly tried to make the xamples shown as bad as possible for ksh/bash/sh:

Examples 3

Find the total bytes used in the current directory

The example is a 6 line script in ksh, or, a 3 step pipeline using awk to do the following:

du -b .

Hmmm...

Example 5

Find out when a process is no longer running.

The example shell script is 11 lines long, features two tests and two pipelines into variables to do the following:

while

ps -e | grep application ; do

sleep 10

done

echo "not running no more"

These are just two - I can see simple little pieces of shell that are trivial to make work on any modern posix system for all the examples provided, except for the laughable

Example 6

where they (Microsoft's rather amazing ksh coders) say there's no way in Unix to see what version of the code is running. Well yes, it's not the shell's job to keep track of that, but anything written using gnu getopts or written by anyone who actually keeps track of versions uses '-v' or '-V' to display that information.

The so-called examples page I linked to is really a page that is designed to convince Windows-only people that they can now have the power we have been used to for 20+ years. Anyone who actually has written any scripts bigger than "echo 'Hello World!'" would be laughing at their examples of "Unix Shell Scripts".