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?

[Philip K Dickhead]

In Vista. ;-)

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?

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

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

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

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

[Thud457]

more like Microsoft POWERVIRUS RC1!

It's in ALL CAPS because it's THAT POWERFUL!

Re:can you?

[msmercenary]

In the current Beta of Vista, the drag/drop into a console is disabled, I'm told for security reasons.

Re:can you?

[Flimzy]

I could have sworn that worked in DOS 6.x...

D:\> c:
C:\> cd d:\foo
C:\> d:
D:\FOO\>

Heck if I'm actually gonna boot DOS 6.x to find out if I'm right, tho...

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?

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

[WeblionX]

No, the point is that you no longer have to type "d:" to change from the C: drive to the D: drive.

Re:can you?

[Flimzy]

oooh. gotcha. my bad!

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?

[interiot]

It makes it a PITA to tab deep into a directory though, because the sequential tab completion means it can't add the final "\" onto the directory name, and then tab complete into the subdirectory without first typing a "\".

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?

[Anonymous Coward]

Another nifty feature Linux/Unix people may not know about cmd.exe is autocomplete. For example, to use it, type: cd c:\docu and hit [tab] to fill out the rest of "C:\Documents and Settings".

Re:can you?

[amRadioHed]

Nifty feature? That seems to me like something obvious you should always have been able to do. I don't use cmd often, but I seem to run into that bit of foolishness whenever I do. That and the pathetic inability to resize the terminal.

Re:can you?

[beemishboy]

Yes, but it is still the same dumb width and you don't get font coloring nor do you get any kind of in file font coloring. I'm glad to see them trying to improve it, but sheesh, this would have been nice like when they released Windows NT or possibly 2000. Now that they have competition with Linux/FF, they have to innovate (PS/MSH, IE). That's the blessing of competition. If Linux or Firefox were the only game in town, it might be a bit better, but competition is a wonderful motivator.

I use a Mac primarily because it's a low-hassle Java development box with a decent user interface and command-line. From what I understand of PSH or MSH, the shell scripting language is more of the system administrator's side of PERL. That makes it nice for system administration, but what about the font coloring and width thing for a user who spends a lot of time in the shell outside of just system administration? Also, it would be nice to have tail and other functionality on the command-line for log files. I would also hope that they improve the services management through the command-line. It's nice right now, but it would be nicer to have something like top or ps or something to see a clear picture of the system information (rather than the process gui thing).

Does anyone know if these niceties are in PS/MSH?

Re:can you?

[leenks]

That isn't the default in Win2K either - you have to enable it in just the same way.

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?

[pla]

That isn't the default in Win2K either - you have to enable it in just the same way.

I'll have to respectfully disagree...

I did not know of the existance of that setting, yet all the Win2k boxen I've ever set up had that behavior by default.

Perhaps different versions of Win2k had different defaults for that setting? Seems an odd thing for Microsoft to tweak, but I seriously have set up no fewer than a dozen Win2k, and they all had cut-and-paste functional without needing to do the annoying right-click-and-select-"Mark" to which XP defaults.

Re:can you?

[killjoe]

You know... Where you put your mouse on the border and then resize the god damned thing like every other window on your screen. Oh and cut and paste like every other window on your screen too.

Re:can you?

[B3ryllium]

Not even WinFX? Hmm. I find that kind of surprising - although I guess I shouldn't, because I'm sure the command line has all sorts of fancy tricks going on so that programs like Oregon Trail can draw properly. :)

Re:can you?

[Doppler00]

You forgot...

keyword = easily

Re:can you?

[Bob of Dole]

But can you actually select text?
Block-select is an abomination. What, do they think we use CMD.exe for ascii art? I WOULD LIKE TO SELECT SEQUENTIAL TEXT PLEASE, MICROSOFT.

Re:can you?

[billcopc]

Ok kids, history lesson! Windows is the successor to MS-DOS. MS-DOS had a wonderful command called "MODE" that let you change text modes. Windows still supports the MODE command to some extent.

the syntax is : mode [cols],[lines]

So the default would be : mode 80,25

In Windows NT/2000/XP and later, you can pick any number of lines and columns. In DOS, 95 and 98, they have to be a legal text mode such as 80x25, 80x43/50/60 or 132x60 on certain displays.

Using the MODE command only changes the window size for the current session. You can set persistent defaults by right-clicking on the CMD window's title bar and choosing "Defaults", then using the dialogs to set your preferred window size and dressing.

Re:can you?

[DA-MAN]

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

You know, nowhere in the gp comment did he mention Linux. . .

Re:can you?

[Excelsior]

In other words, the window is not resizable just like I said. A mode command just doesn't cut it. Use any term on *nix and you'll understand how a terminal should work.

Re:can you?

[Durandal64]

Multiply that by another 10 times if it will actually display the full names of directories instead of "MYDOCUM~1".

Re:can you?

[BrynM]

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

Check out Console. It's a wrapper for cmd.exe or any windows command shell you want (bash, cygwin).

Re:can you?

[amliebsch]

Cripes, it hasn't done that in at least half a decade. Get with the times, man.

Re:can you?

[pumpkinescobarsof2]

very cool, thx for sharin

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?

[Scarletdown]

What was that surprising result supposed to be? I just tried it and all F7 gave me was a single h.

Re:can you?

[palad1]

Mister, I thank you very much indeed.
That is a great tip when one is stuck with cmd.exe and no bash.

Re:can you?

[jericho4.0]

Damit, the suspense is killing me, and I'm not about to install windows to find out. WTF does it do!?

Re:can you?

[Anonymous Coward]

All it does is bring up a command history list

Re:can you?

[moonbender]

Yes, but it is still the same dumb width and you don't get font coloring nor do you get any kind of in file font coloring.

You can adjust the width and there is support for font coloring. The internal commands just don't color anything, cygwin's ls --color works fine.

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?

[cnettel]

Are you sure that's the case even if you enable the separate directory path completion char? That is, PathCompletionChar in addition to CompletionChar. OTOH, I don't see why that \ would be so hard to type anyway...

Re:can you?

[daivzhavue]

You really meant MYDOCU~1.

Spent way too many hours doing W95 support over the phone. Type C as in Charlie, D as in Delta and then hit the space bar. Type M as in Mike, Y as in Yankee, D as in Delta, O as in Oscar, C as in Charlie, U as in Uniform. Now a tilde. That's located next to the One key on your keyboard. Okay, and the number One. Now press enter.

What do you mean The system cannot find the path specified. {wimper}

Re:can you?

[Erik Johnsson]

Linux users are supposed to be smart, not Windows users. ;)

Re:can you?

[oc255]

I think the issue is, cmd.exe is still 16-bit right? I mean, why the crap doesn't the title bar look the same? Why can't I resize horizontally like in OSX and Gnome/KDE?

It's not a serious priority to MS. They want you to use the MMC for everything. And yet, the MMC can't do handy constructs like "for" or "while". CMD.exe is just this huge exception to the rule in Windows and I have no idea why.

Re:can you?

[somersault]

"PS won't be shipped with Vista or Windows Server 2007 but it will debut with Exchange 12.""

Re:can you?

[drinkypoo]

All of those programs utilize the same mechanism, which is present from (IIRC) Windows 2000 on. You can flag windows as transparent and GDI (or GDI+ or whatever it is now) handles drawing the windows transparently. If you have sufficently accelerated video (for instance, any radeon, but not rage; any geforce, but not riva) then the windows graphics driver knows how to produce 2d transparency and there's little to no overhead at the OS level, it's handled by the GPU. Thus, if one fails, they will all fail. Windows simply refuses to draw console windows transparently. My solution (which is highly convoluted, I admit) is to run Cygwin/X and run an xterm, which you can then make transparent with any of the usual utilities.

Re:can you?

[somersault]

it's where Bill Gates keeps his passwords/PINs for safekeeping.. shh

Re:can you?

[Philip K Dickhead]

But it's an add-on by download. It will be available with the release of Vista.

Re:can you?

[drinkypoo]

Now this is exactly what I'm looking for. Why Microsoft can't just give us a decent console window is beyond me. You'd think that stuff like gnome-terminal would have put the idea into their pointy little heads...

Re:can you?

[somersault]

And also any other OS with a .net framework? People are using the beta already without Vista. It also won't be part of Vista. Meh I don't want to start a flamewar, just saying ;)

Re:can you?

[nuzak]

Console is buggier than a jungle outhouse. New tabs don't display anything until some new output arrives in the window, it doesn't display anything for bash at all (not with cygwin's configuration anyway), resizing a window smaller and larger won't redisplay, creating a new tab type doesn't work in the GUI, only by hand-editing the XML, and so on. I didn't try running it long enough to see how stable it is, but I'll suffer CMD.EXE's windows for now, and I run cygwin in rxvt anyway.

Re:can you?

[Tim Browse]

Sorry, I thought about that, and thought I remembered that the one I tried did work on console windows. I guess not.

Next time I feel like being helpful, I'll shut the fuck up, okay?

Re:can you?

[Tim Browse]

That would probably be for the best, since you apparently didn't really read my comment to begin with. I wrote "if only the window could be made transparent". I didn't write, "if only it had a transparency option". To a person with more than two neurons to rub together, these are different statements.

I must have just the one neuron, because neither of those are statements, as far as I can tell.

Re:can you?

[trandism]

Maybe the whole Vista thing should be disabled for security reasons?

Re:can you?

[trandism]

you mean you use it for something else than ASCII-art?? and if yes, i would be really curious to know

Re:can you?

[billcopc]

Yeah buddy I use Gentoo on a daily basis and I know exactly what you're saying. It IS kinda dumb that Windows doesn't offer easy resizing like that, but tough. Linux console resizing has its own string of glitches, often times you have to kill whatever's running in that box and relaunch it, because the average linux teen hacker is "too leet" to implement proper Curses polling.

Tell you what: you get every single linux developer on the planet to clean up their code, and I'll get Bill Gates to personally fix the CMD resizing. Deal ?

Re:can you?

[6th time lucky]

i was gonna say this, but AC beat me too it (and me with no mod points.)

This was a good feature, though.. your cwd was kept seperate on each drive, so you could:

C:\> cd d:\win98
C:\> md win98
C:\> cd win98
C:\WIN98> copy d:*.*

(and run setup.exe to install that pos GUI)

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]

-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

[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

[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-to-now current Windows command shell.

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 know. It is not like you have to either adhere to standards OR have progress. The correct way is to progress through evolving open standards. They wouldn't even have to wait for the standards process to finish as long as they are prepared to change behavior to conform with the standard when finalized.

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

[Philip K Dickhead]

I wouldn't bash* "PowerShell Vista Edition 2007 for Microsoft Windows Platforms" until I actually tried it, folks. PS (for short) is truly an amazing environment for simplifying and automating ordinary tasks from the console. I can illustrate thhis by citing some common operations with CMD.EXE and referencing their PowerShell 2007 equivalents

Monad cheat sheet for cmd.exe users

So, as you can see, PowerShell 2007 is really a dynamic and flexible interactive environment that makes complex tasks simple for administrators. Being able to leverage the PowerShell's "C-like" affinity for whitespace and curly-braces raises a whole new standard of usability.

Re:Text

[Telastyn]

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

I don't know. On another note, I can't understand why modern C++ programmers push for templated classes! Just pass it all in as a void pointer and cast as needed.

Re:Text

[ConceptJunkie]

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

So instead the whole world looks like stupid design decisions from three decades ago...

Still Nonad, or whatever they are going to call it sounds interesting, but I will need someone to explain to me why I should care... and Microsoft is almost never capable of that.

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

[einhverfr]

I wouldn't bash* "PowerShell Vista Edition 2007 for Microsoft Windows Platforms" until I actually tried it, folks.

Right. Don't do as follows:

cat > pstest.ps
#!/usr/bin/pshell // Here is a test program of the MS Powershell in Mono or in .Net via Cywin and Bash... //ToDo enter some code here
^D ./pstest.ps

One should try using it before you write scripts to call from BASH....

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

[drinkypoo]

How does this work besides the "here" syntax? Or is that it?

Re:Text

[mrogers]

Um, it's not just about writing scripts, it's about all of the command-line tools being able to understand structured data. So instead of writing some godawful ad hoc parser in sed or perl to connect two programs, you can just pass structured data directly from one program to the other. ArsTechnica had a nice article about it in October. You can access .NET APIs from the command line, pass objects through pipes without losing type information, invoke their methods at the other end, perform SQL-like queries on pipes, serialise and deserialise objects...

Personally I'd love to have this kind of power in Unix, but you'd have to redesign all the config file formats and the command-line utilities from the ground up... it would be cool, but it wouldn't really be Unix any more.

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

[fm6]

You're being sarcastic, of course, but basing a shell on object passing is actually a pretty smart idea. It's just a form of serialization, which is what any other form of interprocess communication uses. I'm not sure the old Unix concept of building a complex commands out of simple commands and pipes is still viable. But if it is, you really need commands that can handle data more complex than are supported by sort or join. The need for such complexity is why so little scripting is done by bash or csh these days, even on Unix.

The downside with Monad is that you have to have a thorough understanding of the whole .NET object hierarchy before you can even get started. Unfortunately, .NET's designers don't understand something that ActiveX's designers understood very well: that most users of an object framework need to be able to use the framework without becoming experts in the whole shebang.

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

[curunir]

Probably has something to do with the awk/sed/line-noise that tends to make its way between multiple pipes to take string output from one program and pass it to another.

Honestly, what's more readable: (and yes, I realize that this is a trivial example)

ls -la | '{print $9}' | xargs rm

or

del(foreach(dir).getFileName())

The idea of being able to pass objects is a really powerful one that could be extremely useful if it's done with the proper amount of documentation (Unix too would be next to unusable without man find and some of its brethren). However what are the chances that Microsoft got it right?

My guess would be somewhere in the vicinity of `touch hmmm; cat hmmm | wc -l`%

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

[Blakey Rat]

Yeah, why would anybody possibly want to work to improve something? That's ridiculous. Everyone knows that lack of choice in your CLI is the True Unix Way.

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

[ianpatt]

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

Then try using it in a File Open/Save dialog, find that it doesn't work, and notice that it's a one-off hack that I imagine stems from the integration of IE and Explorer...

Re:Text

[peterarm]

They get that *nix's text based communication is a crude and outdated way of doing things

+5 funny

"it works reliably and is simple to understand, therefore it must be horrible"

(compare that to SOAP, which is like the Stay-Puft Marshmallow Man of communication...)

Re:Text

[jrockway]

What exactly is stopping you from passing "structured data" from one app to another under UNIX? Ever hear of YAML or XML?

Besides, what parsing are you doing in a shell script anyway? Most system administration tasks usualy involve the filesystem (accessible via "*" or a similar glob), or reading lines in a file (accessible via xargs or cat) and doing something to them.

Sure it's great that M$ is doing this, but it's no better or no worse than what UNIX has. Why use something that's proprietary and "perl-like" when you can use perl itself for free!?

Re:Text

[taylork]

Can't they have multiple shells?

One where you can use .net objects and a unixy one with things like "bindkey -v" so I can get calls from people who say they can't type things in my window ("you need to hit i").

Re:Text

[jrockway]

> ls -la | '{print $9}' | xargs rm

You mean, rm * .*?

And BTW, I think the shell example is a lot more readable than the MSH example. List all files, print the 9th column of each line, remove the file that's named after the line printed. Simple.

And btw, why would you ls -la | {print $9} when you could just do ls -a | xargs rm?

Re:Text

[admdrew]

Having used the previous Beta MCS, I would definitely recommend trying it out.
I'm not sure why you should care, though, considering you seem pretty much against the whole MS thing. If you're interested, however, run through some examples online after installing it and see what you make of it.

Unrelated installation note:
I had the previous Monad shell installed along with the .NET Framework 2.0. To install this PowerShell, you need the old beta Monad uninstalled (fair, in my opinion). However, to uninstall Monad you need the *beta* .NET Framework 2.0, not the release. Thankfully, I had the old distro package for the beta framework, but it's still annoying to have to uninstall the release framework, install the beta framework, uninstall Monad, reinstall the release framework, and finally install PowerShell. Can't complain too much, though, considering Monad was beta.

Re:Text

[AstrumPreliator]

Notepad is simple and effective, vi(m) is complex and effective. Not everything Microsoft does is bad and not everything the *nix community does is good you know.

Re:Text

[jandrese]

That was my complaint when I tried the previous incarnation of this (MSH). It seemed to take 80 keystrokes to do even simple operations. This felt a lot like a Perl replacement, not a Bash replacement, IE not something you'd use in the command line, but rather a scripting language for when your normal scripting language isn't good enough (which means you'll be getting a lot of use out of it since the normal scripting language is cmd.exe).

Re:Text

[MechaStreisand]

Note, however, that it was a good idea to use a special character to denote arguments to commands. Look at all the problems that can arise in Unix if you ever have a file named -i, or -rf, or whatnot: how do you ever select it? In ways that are different for every Unix utility, or sometimes (most times, maybe) not at all. Plus, using the * wildcard can have interesting results in those cases, although to be fair, that's due to Unix's retarded idea of shell globbing instead of letting the utilities do it themselves with a shared library.

On the other hand, I do dislike Windows's use of \ for directory separation, as that key is in a different place on different keyboards...

Re:Text

[curunir]

I know there are a ton of simpler ways to do the simple task that I chose...I explicitly said that it's a trivial example. I was only trying to find a simple example that would show some of the typical unixy text manipulation functions which obscure what's actually happening on the command line. If you want a more complex example, try this: (a variation of something from O'Reilly's UNIX power tools)

ls -l *.jpg | awk '{print $NF}' | sed "s/\(.*\)\.jpg/mv '&' '\1.jpeg'/" | sh

Useful? yes. Readable? not really.

Something like: (and I've never used MS's PowerShell, so this is just OO pseudo-code, not the actual syntax)

dir.each(file) { if (file.getName().endsWith(".jpg") { file.rename(file.getName().replace("jpg", "jpeg")) }}

For me, despite 7 years of using UNIX as my primary desktop (was Linux, now OS X), the latter is much more readable.

Re:Text

[secolactico]

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.

Funniest thing I've read today. And I spent most of the day reading Fark!

Re:Text

[smittyoneeach]

I do know.
Say what you want, the COM interfaces for VBA coding in MS Office are light years ahead of anything you're going to find in FOSS.
Or does somebody have examples integrating Gnumeric, AbiWord, Dia, MagicPoint, and so forth?
Maybe by LSB 7.0 or so things will have gotten around to standardizing APIs across business applications.
Or not.
Oh, and thanks for the gratuitous downmod, ScuttleMonkey. Have I mentioned how cool you are in the last 10 minutes?

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

[heinousjay]

You must be an astroturfing shill. There's no way you can honestly believe that it's even possible for anything good to come out of Redmond. They're evil. Pure evil. They make money! They must be destroyed! Support choice! Destroy the most popular alternative!

Re:Text

[sconeu]

rm ./-i
  rm ./-rf

Re:Text

[SeeMyNuts!]

It's generally accepted that once you've escaped a special character a dozen times in a regular expression, two awk scripts, a looping construct, and within several variables, it's time to write the program in another language. This is the UNIX shell's way of telling a programmer he/she is wasting time, but only after that time is wasted ;)

See, the escaping mechanisms are supposed to work that way!

Re:Text

[Waffle Iron]

Why not just:

$ rename .jpg .jpeg *.jpg

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

[msuarezalvarez]

Doesn't

  for a in *.jpg; do
    mv "$a" "$(echo $a | sed s/jpg$/jpeg/)";
  done

say exactly the same thing and isn't it notoriously less verbose?

Re:Text

[MechaStreisand]

Good job on missing the point.

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

[I'm Don Giovanni]

Oh I know, because Microsoft really just doesn't get it.

Or maybe you're just another narrow-minded unix geek who's under the delusion that unix and its "isms" are the be-all and end-all. Why don't you actually do some research on Monad before spouting more ignorance?

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

[tomstdenis]

You can grab things with "" quotes. So there is no reason why tools can't glob * themselves.

e.g.

mytool "*.txt"

Will not expand to all your files matching *.txt by bash.

Tom

Re:Text

[Eideewt]

I wouldn't exactly call notepad effective, expecially compared to vi(m). Sufficient, maybe. Notepad is effective in the same way that a bicycle is compared to a car -- you'll get there eventually, but it will take many times as long and you'll have to do all the work yourself. I'd use a car for any lengthy trip, and I'd use a powerful text editor for any in-depth editing. Notepad is for getting finger exercise, saving the environment, and maybe some recreational text-editing.

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

[Coward Anonymous]

The funny thing is that to be truly useful in an "industrial" setting with terabytes of data flowing through the system daily (think Yahoo, Google, Paypal, Ebay, IBM, etc.) all pretty .NET objects and other toys are inevitably discarded in favor of the "crude and outdated way of doing things". It is simple, crude and scales like no .NET object ever can.

Re:Text

[CableModemSniper]

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.

Have you seen Perl 6? I'm pretty sure the dive has already been taken. ;)

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

[dotcher]

What exactly is stopping you from passing "structured data" from one app to another under UNIX? Ever hear of YAML or XML?

The existing *nix utilities are generally set up to output text. If you're in full control of the programs at both end of the pipe, fine - but usually you're not.

Besides, what parsing are you doing in a shell script anyway?

The output of "ps" is a common one, and that can be a pain across multiple platforms. "ps" under Slackware supports a different set of options (and a slightly different default output format) to "ps" under Solaris - this has bitten me a few times in the past.

The idea of piping the output of "ps" (or the Monad equivalent) and being handed a set of process objects with standard attributes to iterate over appeals to me. For one thing, attributes can be referred to by name, not column number. For another, additional attributes can be added to the process object at a later time without breaking existing scripts, or requiring additional flags to be passed to "ps". A space-delimited table is a fine way to present information to a user on a text console... but is it really the best way to present information to another program?

Having said all that... I don't know if the Monad way is intrinsicly better. The Unix model of small, independent tools operating in an "everything's a file" environment is a nice ideal, and works well in practice an awful lot of the time. I wouldn't be caught dead without cat, grep and netcat on any system, and I don't see that changing anytime soon.

Re:Text

[mycall]

Microsoft supports Perl and lots of UNIX stuff. Check out the new SUA built into Windows Server 2003 R2 (well, it is a free download update).

http://www.microsoft.com/downloads/details.aspx?Fa milyID=8b4987e6-d960-49a2-bf52-d3fbd654254c&Displa yLang=en

http://www.windowsitpro.com/Windows/Article/Articl eID/48955/48955.html

Re:Text

[dotcher]

The Win32 API (or at least the CreateFile function - I didn't check any others) will cope with both forward and backward slashes fine. It's not a hack in the shell/IE.

(On the other hand, I don't think forward slashes are officially supported, so the Open/Save common dialogs aren't exactly broken, either...)

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

[shmlco]

"Because computers input/output information just like they did decades ago."

First, the "decades ago" comment was oriented more towards the guy who wanted to know why MS didn't implement BASH.

But yeah. We're still punching 80-column cards and typing on slow TTYs as we did decades ago back in the day. We have to minimize every character used, and to that end we need cryptic vowel-deficit incantations known only to the priesthood and their annointed ones.

"Even the drivers in /dev and operating system internals in /proc can both recieve and output data via text from the shell!"

Sounds like a security hole to me... ;)

Re:Text

[MechaStreisand]

That is true - and it's often needed for some special operations, and for tools such as unrar on FreeBSD (and probably Linux too). My point, however, was that having the utilities doing the globbing should be the default. If they did that, then something like DOS's "rename *.bat *.bak", for instance, would actually be possible on unix; as it is now, any such operation would have to use quotes, as you said.

It sure would be nice if Unix could evolve and improve things like the commandline. Also nice would be if they could simply disallow filenames starting with "-", thus making "-" a special character and making the interpretation of command line arguments unambiguous. I know that all of these things *could* be done, but they aren't. I've long pondered making a version of something like NetBSD with these little improvements in it, or better yet, making patches that people could apply to their existing systems...

Re:Text

[JoshDanziger]

Currently reading: CLASH - Common Lisp As SHell.

Funny, when I first read it, I thought that CLASH stood for "Common Lisp AS Hell."

Re:Text

[cp.tar]

Well, it isn't a really good shell... no tab completion, for one...
So in a way, it is a bit hell-ish. Imagine being presented with good old DOS and having to do something in it...

I only just started looking into Lisp and Prolog; they seem to have lots of potential for language analysis, which is what I need them for.

Re:Text

[mrogers]

Let's say I want to work out whether any network interfaces that use DHCP are currently configured. Under Unix I'd have to do something like the following:

1. Read the interfaces(5) man page and write a parser for the unique file format
2. Read the ifconfig(8) man page and write a parser for the unique output format
3. Write a tiny bit of glue code to connect my parsers

With MSH/Monad/PowerShell, I'd only have to do number 3. It's not a question of doing anything that's impossible under Unix, it's just a question of making things easier. Like I said in my previous post, you could rewrite all the Unix command-line tools to understand XML, you could replace 1001 config file formats with XML, you could give bash an SQL-like filter syntax and access to an enormous standard library... and I hope someone does. Someone with more time than me. ;-) But so far MS seems to be ahead in this particular area.

Re:Text

[Eideewt]

Chill, man. I'm just talking shit about Notepad, not your fancy new shell. It may be wonderful for all I know.

Re:Text

[EvanED]

something like DOS's "rename *.bat *.bak", for instance, would actually be possible on unix

I have found myself in want of this on a number of occasions in Unix. Any Unix guru have a solution? Will it work if you change "rename" to "mv" and quote the file patterns? I tried it on Bash under Cygwin and no luck...

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

[anagama]

You can't do a "mv *.bat *bak" command. You need a short script, can be a one-liner:

for i in *.bat; do mv "$i" "`basename "$i" .bat`.bak"; done

This would change all the bats to baks. Note the backticks around the "basename" description. Somewhat easier for me to remember is something like this:

for i in *; do mv $i `echo $i | sed -e 's/FROMtext/TOtext/'`; done

On a whim, I did "man rename". Looks like "rename" will do what you want too, but not exactly like you describe.

rename 's/\.bat/\.bak/' *.bat

Note the escaped periods.

Re:Text

[anagama]

for i in *; do mv $i `echo $i | sed -e 's/FROMtext/TOtext/'`; done

Note that this should be: for i in *.bat ... etc.

I'm not a guru BTW, test on junk files before using!

Re:Text

[Ruphuz]

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

Nonsense. That would like saying English people purposefully drive on the left to make a difference.

Er, wait...

Re:Text

[sg_oneill]

He's talking about /dev dude.

Linux has somewhat subverted this to a degree, but you used to be able to do MAD things with /dev.

One of my old fun tricks was to try and grab hold of the filehandles from the old uni unix terminals (lol root password = secret) and pipe them into each other in a script to make peoples terminals do batshit crazy things. Another trick on the more modern linux, is/was to pipe a core dump to /dev/dsp (sound system) and listen to the hiss. Aparently , Im told, theres a midi device that makes mad music when you pipe junk to it.

Heres the secret clue to all unixes and most of linux: Everythings a file. *Everything*

Re:Text

[mindriot]

Even simpler:

for i in *.jpg; do mv "$i" "${i%.jpg}.jpeg"; done

Re:Text

[sg_oneill]

Oh, and regarding that root password, this was a good 12-13 years ago. Don't even bother script kiddies.

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

[Anonymous Coward]

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

Whether you like to admit it or not, text is an arbitrary, difficult to debug format. If your data are structured, then that structure has to be encoded somehow in the text. And everybody and his uncle has a different preference as to how to do that encoding.

Re:Text

[cyber-vandal]

leverage is a bloody noun ffs !!!!!!111one1!!

Re:Text

[Chris_Jefferson]

Because then I could write scripts that don't break horribly when someone has a directory with a space in. Seriously, they should just never have allowed those, it would make life much easier.

Re:Text

[giliposha]

Usually -- denotes the end of parameters so:

rm -- -filename

Re:Text

[Gorshkov]

Um, it's not just about writing scripts, it's about all of the command-line tools being able to understand structured data.

There's only one small, slight little problem with that .......

The WORLD is unstructured, and it's data reflects that. In narrow domains, for specific applications, you can define & impose structure on something - but to anything outside that domain, the structure is meaningless ... and therefore, appears to be unstructured (even if it is formatted all nice and pretty)

Re:Text

[Gorshkov]

dir.each(file) { if (file.getName().endsWith(".jpg") { file.rename(file.getName().replace("jpg", "jpeg")) }}

for i in *.jpg
do
mv $i `basename $i`.jpeg
done

Personally, I think I'll go with Door #2 .........

Re:Text

[smittyoneeach]

How can this be? DCOP has no 'K' in it. ;)
Seriously, thanks for the link.

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

[ookaze]

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

BS, Unix was using them extensively already. Get your facts straight, MS said they did that to avoid being accused of copying Unix technology. The other reason is the one you cited. But directories existed already.

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

BS again, '\' was there from the start, with a variable you could set to use '/' instead.

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.

Which was the case. And they have a big advantage : they were working with IBM, which was a HUGE advantage. Again, get your facts straight.

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.

BS, there are a LOT of technical and other reasons for not doing that.
Do you understand you need to load all this when starting your OS ? On Unix, you are not even sure to have all your libraries when booting your OS.

Re:Text

[bheer]

They don't have a problem making Perl available for customers who want it (Unix migrations mostly) but a large chunk of their customers (CIOs) are quite clear that they don't want their IT systems running on scripting duct written in $flavor-of-the-month language. I have personally seen this hostility-to-scripting at work; and again, it's not because CIOs don't grok Perl/Python but rather they're concerned about not having the skills required to maintain these scripts.

I should probably point out that I personally think these customers are wrong -- Perl code written to standards isn't write-only, and people who don't like Perl's syntax can use Python.

That said, Microsoft didn't get rich by lecturing their customers about best-practices but by delivering what they wanted. And from a product development standpoint, owning your own scripting language makes perfect sense.

Re:Text

[Achromatic1978]

Out of curiosity, what standard defines the Bourne Again Shell, exactly?

Or is this just a pointless jibe at Microsoft? I suspect so.

Re:Text

[Pius II.]

Forward slashes are officially supported, and have been so at least since NT 4. There is documentation on this here.
I remember that there's even some document wholly dedicated to this problem somewhere, but I really can't be bothered to find it.

I also like the sentence "In this version of Visual C++, UNIX compatibility information has been removed from the function descriptions."
Thanks for helping, MS!

Re:Text

[LazySlacker]

I would point out that us English only drive on the left in countries where the vast majority of people drive on the left, e.g. England, Wales, Scotland etc.

We drive on the right in those countries that drive on the right, except when just off the ferry/train when we forget :-)

Re:Text

[bheer]

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.

I wouldn't have to. If I know they own a product that includes Monad,
I'll just give them the .ps? script. (And if they didn't, I'd find out
what's acceptable and give them one of (Perl, Python, hell C).

And Microsoft's customers using Monad get free support and updates _for
that version_ for seven years (and four more if they pay IIRC), thanks
to MS' lifecycle policy. And since they own the software (unless the
leased it) they have rights to continue using it after that.

Most people who buy, use and work with Microsoft products know the
implications of using Microsoft products. If you insist on assuming
everyone else is an idiot, more power to you. Meanwhile, I'll just get
on with my work.

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

Considering that IE4 was the first browser with a decent programmable
DOM, I'd say they were quite a bit better. Except <marquee> (but
then Netscape did <blink>). See also XMLHTTPRequest.

> The MSFT way is just "different" but not because they want to do
> something that is fundamentally better.

Actually, what MS does is what any software company should do--

a) ship products that work well together
b) Give customers technological and financial incentives to buy more of your products
c) Think about your customers first (my interpretation: think about your critics and
reluctant customers later)

It's a very simple philosophy that actually used to be written down on
old DOS manuals. Everything MS has succeeded at has followed from
these: Windows worked well with DOS, their Word processors and
spreadsheets etc worked well with Windows and DOS, their directory
offering worked well with their server OS, etc. Microsoft calls it
'integrated innovation' nowadays -- the 'innovation' may be
marketing-speak but the integration is real. It is also the opposite of
the Unix philosophy, which is small replaceable tools: MS'
products fit together all right, but they are rarely small and even more
rarely easily replaceable.

> It's simple economics. If you can isolate your customers from your
> competition you rule them all.

I'm sure MS' marketers love that, but the real reason product companies
tend to develop their own rather than work with an outside technology is
a combination of risk mitigation and effort: using outside products
entails risk (hint: SQL Server 2005 took a risk embedding the CLR within
it, Vista took a risk in trying to use the CLR for everyday objects like
the shell and then decided it was a bad call) and more often, developers
find 'rolling their own' to be easier to maintain (and in the case of
software companies, to support) than working with someone else to
integrate their software.

> If OpenOffice can run on a dozen platforms

Last I checked it (OO.o2 RC1 I think) it still ran _badly_ on several
platforms I tried it on. For all the cribbing about bloat, Word/Excel
etc start _fast_. OO makes my machine crawl.

And besides, for all your implications about how Microsoft products are
inferior because they only support one platform: here's a clue. Real
users care about only one platform-- their own. Cross-platform is
nice-to-have, but some folk on Slashdot (typically academic CS types and
Unix geeks) have a _very_ overblown idea about its importance.

(And this is from a guy who has at this moment a Windows box, several
Linux boxes and a BSD box in his general vicinity. And yes, I do have
Perl (and vim) on all of them. But I'm under no illusions that my needs
are 'typical'.)

Re:Text

[theolein]

Or maybe it'll run on Mono. Mono is fast turning into exactly what about 80% of us predicted it would: a system that no one will touch with a ten foot pole. Or do you know any enterprise applications written in or running on mono based systems? (Not that you, as an MS cocksucker, would know anything else than windows)

Re:Text

[tomstdenis]

bash is compatible one way or another with shells dating back to the "day". This is what we call a "de facto" standard.

A script I write for bash will likely work for tcsh or ksh. A script I write on my Gentoo box will likely work on a *BSD box with bash, etc, etc, etc.

One of the more annoying things about windows was the inability to run shells developed ELSEWHERE on it. It's bad enough none of the MSFT tools support gmake (which even *BSD and MacOS toolchains do) but not being able to script is annoying. Now they come out with a scripting language, which for all intents and purposes may be very elegant and useful, except it's totally incompatible with anything else.

For software vendors who target more than Windows this has always been a thorn. Let's not forget Windows still provides no POSIX.1 [or .2] compatible API for developers. So kiss things like pthreads goodbye. mmap? Who needs that. etc, etc.

This would be different if this was 1983 or something. Then you could say they're really trying to innovate since the alternatives are in proprietary UNIX OSes and not really that pretty (I think most shells before bash were painfully inept). But today? After all the other standards they have abused... it's hard to be accepting of yet another tool that is incompatible.

Tom

Re:Text

[tomstdenis]

Most people who buy, use and work with Microsoft products know the
implications of using Microsoft products. If you insist on assuming
everyone else is an idiot, more power to you. Meanwhile, I'll just get
on with my work.

I don't think you grasp the implications here. You're saying you're free to use a binary only copy of a tool. I'm saying I'm free to DISTRIBUTE tools like Perl even with my own tweaks if I want. This is especially important after platform changes (e.g. say when glibc goes to 2.5 or something and I have to rebuild it).

Last I checked it (OO.o2 RC1 I think) it still ran _badly_ on several
platforms I tried it on. For all the cribbing about bloat, Word/Excel
etc start _fast_. OO makes my machine crawl.

I dunno where people get this but OpenOffice loads fairly quickly on both my WinXP laptop and my Gentoo desktop. Certainly not significantly slower than Office. It's entirely possible your HD is horribly fragmented or you're comparing a cold start of OO to a warm star of Office?

And besides, for all your implications about how Microsoft products are
inferior because they only support one platform: here's a clue. Real
users care about only one platform-- their own. Cross-platform is
nice-to-have, but some folk on Slashdot (typically academic CS types and
Unix geeks) have a _very_ overblown idea about its importance.

Um how about not? The inability to work with Office files in Linux an annoyance beyond belief for many Linux users who relunctantly boot Windows [and then get infected with CWS ... thank you IE] to use the tools. I'm sure if you explained to your boss how you could save $100s per box by not installing Windows they might be interested.

Defeatists like you are horribly annoying. Oh, Linux isn't perfect so let's totally ignore all it's positive qualities in favour of the path of least resistance. Even though in the long run this just sends us down the path of servitude. Yeah, so much better.

Tom

Re:Text

[richlv]

"Even the drivers in /dev and operating system internals in /proc can both recieve and output data via text from the shell!"

Sounds like a security hole to me... ;)

why ? would accessing them through a gui would be more secure ?

Re:Text

[CastrTroy]

Well then why don't they point that out in the linked article. Why even tell people that they should type "set-location" when "cd" will do just as well. Anybody familiar with shell scripting already would know what "cd" meant. Why make up a whole new command? This looks more like something you'd want to buy an IDE for than something you'd just create to save time.

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

[makomk]

"Even the drivers in /dev and operating system internals in /proc can both recieve and output data via text from the shell!"

Sounds like a security hole to me... ;)

Not really - you're restricted by file permissions, just like with any other file...

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.

Re:Text

[just_another_sean]

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.

--
Karma: Excellent (time to start trolling)

Somebody obviously didn't get their wheaties this morning...

Re:Text

[Uzik2]

I'd rather not have objects of any kind. The power of the command
line is that you can take any output and process it using any of
the tools. Objects will just make tools not compatible with data.
It's just what happened when they 'objectized' the clipboard in
windows. Now I have programs that can't cut/paste.

Re:Text

[Dan Ost]

I work at a Fortune 150ish company where our some of our development groups are moving to .NET. It is my understanding that all of the back-end stuff (nothing requiring pretty UIs for the customer) is being tested to run both on MS's CLR and Mono. The customer facing stuff uses windows forms, so it won't do Mono.

I don't know who set this policy, but I think somewhere along the way, someone decided that the back-end stuff should be able to run on Linux. Hence, the Mono decision.

Re:Text

[richlv]

are you SURE you just didn't press tab twice in the wrong console ? ;)

Re:Text

[TheNetAvenger]

Then try using it in a File Open/Save dialog, find that it doesn't work, and notice that it's a one-off hack that I imagine stems from the integration of IE and Explorer...

This is due to the common dialog library that applications use (It is the one carried over from Win32/Win95 and not a real NT level system API control(ie. it was designed to support FAT32 on Win95).

Also an FYI, this no longer exists in Vista, and even newer applications, as they use the updated Common Dialog Controls.

Re:Text

[TheNetAvenger]

Ok, this is where people step into the room and go, ok but that line look really messed up to a Windows user that is use to wrtiting faster and simpilier syntax.

Besides, I truly don't get the huge reluctance to special character restrictions. This is what the basic constructs of programming and scripting and syntax are all about. Even funadmental concepts that came out of the early *nix years proved that reserved words, operators, etc were a key to a non-fragmented UI consistency. (Even though some of the tools that have survived just shouldn't have.)

I see benefits in both. Windows has the ease of use, and still can leverage some pretty powerful command line abilities if needed. Also Windows has universal scripting languages, like Javascript and VBScript that can not only be used from the GUI, but also in the shells, and especailly in the new Monad Shell. (And with the .NET framework at play here, strap on Python or whatever that is .NET able and run with it, both in the CUI and GUI.)

I find it strange that people here drawing a line in the sand saying the Windows based implementations are bad or the *nix concepts are wrong.

What next, lets propose that in C++ that the + and - signs are no longer reserved operators as well? Just so I can have a variable named Donkey++ and not have it self increment?

I get what people are saying, and a lot of this has to come from the style they are used to, but either side doesn't stop and realize there is ease of use and flexibility offered on both sides of the fence, even if it is not completely obvious because you haven't worked in one as much.

The Windows people haven't seen the power of the inherent in/out structures that are fairly universal, nor have they seen the inline scripting power.

And the *nix people have completely missed the standardized syntax with object and OS Object model referencing, and also have missed that because of .NET inherent scripting get extend from the GUI VB/JS then add on the language independance of .NET so strap on whatever scripting language makes you feel good, find the .NET version and use it as well, like Python, etc.

MS actually gets this better than the *nix would would like to beleive, and this is another case of underestimating MS.

Also another problem in the *nix concepts, even on this subject is how IMPORTANT 'internal' standardization is. Diversity is great in some eco systems, but when trying to establish common interface concepts, the staple of Windows development side success, what MS is doing is important, and it would be better for *nix competing tools like Bash, etc to agree to some common CUI constructs, or at least merge what is currently similar, leave in legacy, but make all new OS interface handlers adhere to a structure.

People forget the success of Windows pre-market gorilla, was the ease and consistency for developers in 1990-1992. More applications were made easily those year for Windows than any other OS had ever seen in history. (VB and the cheap tools from MS helped a lot, and developers are as much to credit the early success in though years as was the end user adoptation.)

Re:Text

[Forbman]

But how well will PowerScript work with scripts that use the objectified system access stuff they have now (WMI and ADSI)?

The core language syntax could definitely be better than VBScript, yes.

Me? I'd much rather hope for someone to "rubyize" ADSI and WMI for Ruby.

Good thing it won't work on Windows 2000, so I won't bother looking into it.

Re:Text

[poot_rootbeer]

Of course we could all just use XML and YAML, we just have to rewrite every app to serialize and unserialize these grotesque formats.

Or, we could all just use .NET objects. We just have to rewrite every app to serialize and unserialize that grotesque format...

Re:Text

[Forbman]

The only problem is that DEC didn't have much/anything to do with CP/M. It is entirely possible that CP/M cribbed a lot of its ideas from VMS (if they did they may have taken 8.3 file names, "/", etc., but they didn't take ";#" to indicate file version numbers...).

Re:Text

[Forbman]

BS, Unix was using them extensively already. Get your facts straight, MS said they did that to avoid being accused of copying Unix technology. The other reason is the one you cited. But directories existed already.


Funny, somewhere along the DOS 3.0 line they added ">","",and "|", which kind of work like they do in Unix, redirecting streams, etc.

Re:Text

[Slime-dogg]

Not that I particularly care one way or the other, but I may as well make commentary in a few places.

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.

The go back to your other point, where, to paraphrase, "if MS decides to move on, are you going to ship an old version of Monad..." So, if a client has moved to Perl 6, or has the original unmodified Perl 5.xx, are you going to force your client to accept your "fixes" to that Perl? I don't see how this is much different than requiring a client to use an older version of some other system internal.

Also, I'd like to point out that ASP.NET, in particular, is quite different from PHP. Where one is interpreted, the other is compiled to IL, and then to machine code by the runtime. That code is cached, so subsequent executions of that page are much much faster than the first, as opposed to the old interpreted ASP or PHP way. Yes, there is little difference between this and CGI, with exception that the libraries are far easier to use in .NET.

Yes, you are at the mercy of MS, when it comes to very specific applications, however, the framework that Monad is built upon is an ISO standard, I believe... and is not so likely to change. MS took that step to ensure that the important bits of the .NET framework won't change. If worse comes to worst, you can roll your own script interpreter, using .NET.

Your arguments seem rather uninformed, and FUDlike, than anything. It goes both ways. You have MS zealots, who delight in remaining ignorant of OSS, but on the flip side, you have hot headed OSS zealots who do the same. Sometimes, you have to choose the right tool for the job you're doing. If you find yourself in a pure MS environment, perhaps using MS tools, and a flexible and powerful tool like PowerShell TM would be just the thing to use.

Re:Text

[orcrist]

Ever heard of 'mmv' (multiple move)? In at least SuSe it's standard. It allows globbing, regexes, placeholders, and it refuses to do anything which looks remotely unsafe (like overwrite any files without confirmation, etc.)

That's the only tool I use on the command line for renaming/moving more than one file.

-chrs

Re:Text

[mrogers]

The WORLD is unstructured

The scientific worldview begs to disagree. ;-)

Re:Text

[rufus t firefly]

As this drifts further and further off topic ...

Bash actually has the ability to do most of that with built-in functionality, so you don't even really need sed:

for FILE in *.bat; do mv -v $FILE "${FILE%%FROMtext}TOtext"; done

Re:Text

[stikves]

No I was also surprised too :)

I mean I did not expect to do "man ls" on a microsoft shell, but it actually runs.

Re:Text

[__aaklbk2114]

If Microsoft could produce an operating system that eschews Win32/Win16/DOS et al completely and is pure .NET...

Have you seen Singularity?

I so wish MS would drop Win32 et. al and replace it with this. Singularity has some very cool ideas.

Some other cool Singularity vids:

http://channel9.msdn.com/ShowPost.aspx?PostID=6830 2

http://channel9.msdn.com/Showpost.aspx?postid=1418 58

Re:Text

[nuzak]

You really don't comprehend the idea of doing something that's not a built-in command, do you? Still, as a textual manipulation, it doesn't need much new syntax...

ls *.jpg | while read file; do mv $file ${file%jpg}jpeg; done

(And if you're not concerned with filenames being generated by a command and you don't have thousands of files, you can just turn it into a single "for file in *.jpg" loop)

If the gp's post is what object shell's syntax looks like, I want no part of it.

I also have lots of reports where I have to pass tables around. It'd be nice if I could work with the rows AND columns in an ad-hoc shell pipeline without having to roll my own parsers for it.

But like I said (more like trolled) earlier, I don't really have to ask for such a feature -- it's already here in Windows, and perhaps in Mono soon. Technically there's nothing preventing you from piping any arbitrary format you want in Unix, just that there aren't any decent CLI-based parsing tools beyond the really trivial in the GNU toolchain, let alone POSIX.

Re:Text

[Yankovic]

Um, I'm an admin, and there's nothing that annoys me more than having to parse out ps -aux to find the process name, percent cpu, etc. with this, it's an object, so i can just query it for the property. Works ridiculously well. Trust me, not having to parse reduces errors hugely.

Re:Text

[nuzak]

That's not what basename does. ${i%.jpg} is what you're looking for.

Re:Text

[squiggleslash]

I've vaguely heard of it but not seen it. It's certainly where operating system design should be heading, IMO.

I'd like to see the Free Software community take this ball and run with it too.

Re:Text

[bheer]

I don't think you grasp the implications here. You're saying you're free to use a binary only copy of a tool. I'm saying I'm free to DISTRIBUTE tools like Perl even with my own tweaks if I want. This is especially important after platform changes (e.g. say when glibc goes to 2.5 or something and I have to rebuild it).

That bit about glibc breaking stuff is a classic open source problem that isn't even recognized as a problem. I can run Classic apps on OSX without recompiling anything. I can run Visicalc on Vista. No recompiling involved. "The source is available" is a lousy excuse for ABI breakage. (And don't quote me RHAT's intra-version ABI compatibility as a good example. IT guys might be okay with that (although I doubt it) -- it's completely unacceptable for end-users.)

And yes, I do know what Perl's artistic license implies. So now you're going to tell me that my enterprise is now dependent on a custom build of a hairy interpreter codebase that's done by _you_? That sounds like a good story for you to get consulting income, but I'd be a dunce if I chose that route.

Defeatists like you are horribly annoying. Oh, Linux isn't perfect so let's totally ignore all it's positive qualities in favour of the path of least resistance. Even though in the long run this just sends us down the path of servitude.

Servitude? wow. I somehow doubt you even know what that word means.

Anyway, flowery language aside, I'm not interested in your holy wars. No, really. I have other things to do and my own products to take care of. And I'll use whatever operating system/tool is most suitable for the job.

> I'm sure if you explained to your boss how you could save $100s per box by not installing Windows they might be interested.

Most Fortune 50 companies I know of (about 20 of them, admittedly not a comprehensive sample) pay $18-$30 for their per-seat Windows licenses. At those prices it's not worth subjecting users with training on an unfamiliar system, especially when the unfamiliar system is also more expensive (OSX) or sub-par (Linux).

Re:Text

[shaitand]

'Ok, this is where people step into the room and go, ok but that line look really messed up to a Windows user that is use to wrtiting faster and simpilier syntax.'

I missed where that was relevant. This was an offtopic thread where someone asked how to accomplish a task for informational purposes, not to raise a challenge.

Aside from that, it is true the windows way is faster (in the sense that it requires fewer keystrokes). The problem is that the windows way lacks logical consistancy. On one hand, that syntax is something that one might try. On the other hand, it does not complete a complete logically consistent system of shell function. The for command makes sense, it has a clearly defined function and behavior that can be expected. The same is true of all the core functions in *nix.

When you encounter a problem, you can pull out that *nix toolset and craft a solution using tools that function in exactly the way logic requires. Logic says that passing rename a list of files and asking it to rename it to an empty list of files will not work.

The *nix shell is a logical structure. Because it provides the functions needed to fill the logical way things work (like the ability to individually modify each element of a list of elements with a single command) and a structure that lets you suture them into custom solutions; the strongest of power users will not be willing to replace it with a different tool unless that tool improves upon this core principle of design that defines the best TOOL for ANY task (not merely shells).

The windows shell (and much of microsoft interface design) does not provide a complete logical structure. Instead of providing a complete logical structure, the windows shell operates on the principle of wishful thinking. For instance, this rename command. The syntax listed earlier is intuitive in the sense that a user is likely to try it, but the user would try it with fingers crossed because it doesn't really make sense. You can't close your eyes and picture the digital gears and pullies that would make the function work that way. The user would be pleased because the software worked the way they 'wanted' it to. But this design philosophy means that are always guessing and memorizing behavior. Design by what the typical guess is nice I suppose if you are typical and probably quicker to learn since guesses yield fruit. Design by logic will always provide a system that is more complete, and allows more rapid problem solving once learned.

To make the point using the same example in another way, it is worth pointing something out. Those who mentioned the windows way, know the windows way because they discovered it and remember the syntax. Those who listed the *nix way even said to check it first. Why? Because the *nix guys solved the problem by crafting a solution from components of a logical system and having a mastery of that system, not by lucking out and having a 'trick' syntax for that particular function.

* It should be noted that there are no shortage of trick syntaxes in the *nix world, especially in GNU tools. But knowing these is not required to craft a command line to solve a problem. Rather than being THE way to do something, these are merely alternative ways to do those things that might save a few keystrokes if you happen to be familiar with them.

Re:Text

[Gorshkov]

actually, it does - but I forgot the proper invocation

basename /x/y/z.jpg
z.jpg
basename /x/y/z.jpg .jpg
z

Re:Text

[tomstdenis]

That bit about glibc breaking stuff is a classic open source problem that isn't even recognized as a problem. I can run Classic apps on OSX without recompiling anything. I can run Visicalc on Vista. No recompiling involved. "The source is available" is a lousy excuse for ABI breakage. (And don't quote me RHAT's intra-version ABI compatibility as a good example. IT guys might be okay with that (although I doubt it) -- it's completely unacceptable for end-users.)

For the most part from version to version glibc is backwards compatible. So no relinking required. But things change. When AMD64 came out the ABI had to change to accomodate the platform. That's unavoidable.

The point is though if there is an ABI change having access to the source lets you port things up.

And being able to run Visicalc from DOS 2.0 days on Vista is not always a "good thing". I can run that in Linux as well with DOSEMU but I have to choose to install that "baggage". Vista [or windows] gets it to you as a value-added bonus.

Most Fortune 50 companies I know of (about 20 of them, admittedly not a comprehensive sample) pay $18-$30 for their per-seat Windows licenses. At those prices it's not worth subjecting users with training on an unfamiliar system, especially when the unfamiliar system is also more expensive (OSX) or sub-par (Linux).

You're missing the whole "support" contract issue there. First off, when you have 50,000 employees even $30 per seat adds up. Then you add in the custom support you can only get from one place [e.g. MSFT] and things start looking like reality.

MSFT didn't get rich off of $30 per seat.

I like the jab at the end about "or sub-par (Linux)". Good to show you're not fighting any sort of OS holy war. Wouldn't want to see that.

Tom

Re:Text

[nuzak]

Spiffy, I never knew it had that feature! That should take a little of the line noise out of some of my scripts :)

Re:Text

[Gorshkov]

amazing the things you can learn when you read the man page, ain't it? :-)

Re:Text

[bheer]

> First off, when you have 50,000 employees even $30 per seat adds up.

And of course, deploying Linux for 50,000 employees (including the moonbats, er fine people in HR) is cost-free. heh.

> MSFT didn't get rich off of $30 per seat.

Oh yeah. I agree. I'm just pointing out that for many companies Windows is cheaper than you think. And Linux advocates who think that a 'free' OS == world domination don't help. There was a good article on digg yesterday about this.

> I like the jab at the end about "or sub-par (Linux)". Good to show you're not fighting any sort of OS holy war. Wouldn't want to see that.

Heh. So Linux desktops get a free pass from usability because it's open source? Please. Off the top of my head: Linux desktops have

• case sensitivity
  
• very flaky hardware support
  
• visual inconsistencies (try running Gnome apps on KDE and vice-versa)
  
• scary interface conventions for Windows users (why does Gnome have no cancel buttons? lots of users I know get scared with that)
  
• advocates who bleat about 'idiot vendors not open sourcing their drivers' or 'choosing distro X will solve your problem!' or 'so roll your own distro' when told about these problems, further alienating users who want to use a Linux desktop to get his freaking job done.
  

PS. I currently run Gnome on one of my Ubuntu workstations (primarily so I can use dvd::rip's GUI). It's come a long way from Redhat 4's twm, but the thing is -- both Windows and MacOS have improved since RH4 too. Linux desktop advocates do themselves no credit when they compare Linux desktops with Win9x -- it just makes them look dishonest.

I have not yet used a Linux desktop that feels like a cohesive whole -- every one has felt like its been cobbled together by lots of different people, which is actually true given it's open source -- but why should users who care about polish have to suffer a cobbled-together desktop that Linux offers today?

Re:Text

[tomstdenis]

Problems you listed are funny.

Case sensitivity? What like having real file names? I guess you're a fan of 8.3.

Hardware support? That's funny because my workstations, laptops and servers all run Linux based distros. In the past five years I haven't had any problems with hardware that Windows handled any better. If you mean lack of drivers then you just have to be smarter about what you buy. There is plenty of performance and econimical hardware that is Linux supported.

Visual Inconsistencies? That's cute. I can't imagine any computer literate person having a significant problem moving from Gnome to KDE or vice versa. Also many applications are GTK based which means it doesn't really matter what your WM is.

Yes, moving to a Linux distro is work. But in the long run it's worth it. Having freedom of choice means you get "scary number of things to look at" but it also means that some asshat in a suit in Redmond can't tell you what you can and can't do with your computer.

Tom

Re:Text

[bheer]

Your attitude of "you're too stupid to appreciate the beauty of Linux" is an almost-perfect example of one of the biggest problems with Linux -- advocates whose answer to everything is "it's a feature!" and further alienate users.

I think I ought to add a *big* benefit under the Windows' column -- absence of obnoxious advocates telling users how they're too stupid to appreciate the desktop. Come to think of it, even OSX has its wingnuts but even they're better than the samples that inhabit the Linux community.

Re:Text

[tomstdenis]

The problem people like me have is people like you just keep saying Linux is hard, Linux doesn't work, Linux is bad.

Yet millions of people like me just go ahead and get work done efficiently on Linux based distros anyways.

And what is so hard or bad about OSS distros? Oh there are choices, you have to know how your computer works [at even the most basic levels] and you have to know what you want to do with the computer.

Why are those bad things?

Tom

Re:Text

[bheer]

The problem people like me have is people like you just keep saying Linux is hard, Linux doesn't work, Linux is bad.

It wouldn't be a problem if you saw it as constructive criticism and tried to figure out what users wanted from a desktop instead of expecting everyone to agree Linux desktops are the cats whiskers. And notice that this entire discussion has been about a linux *desktop*. I see no dissonance about waxing rhapsodic about the Linux command line or Linux as a server/network appliance (in fact, as I probably mentioned before, I use several Linux and BSD boxes at work -- by choice, because they were the best tools for the job) and and simultaneously bitching about how it sucks as a desktop.

> And what is so hard or bad about OSS distros?

The point is not about 'hard' but about why the user has to think about them at all. Most of Linux's desktop woes are fit-and-finish problems (therefore iteratively solvable, in fact we do see some progress with each distro iteration) but the rest are boneheaded design decisions that appeal to people who were weaned on Unix and X but leave others cold.

That's the reason why Apple (which is wedded to a great user experience and the bottom line, not any particular technological 'purity') chose a BSD core with their own GUI layer: there was no other way they could have provided a great user experience using freely available desktop solutions.

Re:Text

[tomstdenis]

I'd like to think things are getting better. People like you should have been around in the early days of Linux where distros were installed off of floppy disks and WMs were usually crude [e.g. just enough to move windows around and what not].

What you have to realize is that the OSS community is not collectively working on the gui side of things. There are people working on the kernel, the compiler tools, the userland tools [e.g. ls, cp, cat, etc], the networking tools, the admin tools, the X11 system, the WM tools, the desktops, the browsers, the multimedia libraries, the media playing applications, the IMs, the image tools, the scanner tools, the games, the web servers, the file servers, the databases, etc...

So it isn't like all 100,000 OSS developers just get down in a convention centre and discuss how to make KDE more like WinXP.

Also if your logic is correct about the need for a shiny OS then the IBM PC would have been the LARGEST FINANCIAL DISASTER OF THE COMPUTING INDUSTRY.

Fact of the matter is the typical computer user today is not that of yesteryear. Perhaps that's good perhaps that bad.

I like to think that computers can be taught in schools [and are] and that not enough emphasis is placed on actually understanding at least fundamentally the technology behind a computer.

I think it's a bad thing to say "let's hide all those nitty gritties from the users". Sure, there is a limit to this, a line must be drawn. Should the average user know what page tables are? Or what an exception handler is? Perhaps not. But forcing them to know what a directory is or device driver is not such a bad thing.

Average home users were more interested back in the day. It wasn't just computer scientists buying the IBM PC, it was families who realized the potential and wanted to be part of something that was growing. They taught themselves how to use DOS when it was nothing but a single-user command line. They learned how to edit batch files and sort their files by themselves. They were not lazy.

But look where ease gets us today. Vendor locking with Office tools, drivers for PCI hardware that only works in windows, the inability to maintain our own computers [e.g. remove viruses, keep from getting them in the first place, add our own drivers, etc] and so on.

Is giving up your ability to really choose worth the fisher price GUI sitting on-top of an incompetent proprietary OS? It wasn't worth it in the 80s [hence FSF] and it sure as hell isn't worth it today.

Tom

Re:Text

[TheNetAvenger]

The windows shell (and much of microsoft interface design) does not provide a complete logical structure. Instead of providing a complete logical structure, the windows shell operates on the principle of wishful thinking. For instance, this rename command. The syntax listed earlier is intuitive in the sense that a user is likely to try it, but the user would try it with fingers crossed because it doesn't really make sense. You can't close your eyes and picture the digital gears and pullies that would make the function work that way. The user would be pleased because the software worked the way they 'wanted' it to. But this design philosophy means that are always guessing and memorizing behavior. Design by what the typical guess is nice I suppose if you are typical and probably quicker to learn since guesses yield fruit. Design by logic will always provide a system that is more complete, and allows more rapid problem solving once learned.


See I don't disagree with you on this, or pretty much anything else you said.

However as for relevance, people were dissing the new Shell technology that Microsoft is developing, many that have no idea how it works, what it gives access to, etc.

What I quoted above from what you said is a good example of why the new Shell technology from Microsoft is a step in the right direction. Not only have they went back to the drawing board basically, but have approached it with a new approach of making syntax more consistent, while adding in a whole new level of command line functionality.

Sure most of Windows (Especially XP & 2003 Server) have evolved to have command line tools to manage the system, but they are fragmented tools that don't have consistency. The existing CUI in Windows in many ways is just a replication of DOS syntax with adaptations to make it fit in the NT world.

The new Shell is to address this, and to give Windows a solid command line system that works based on the WindowsNT model and take various concepts from many areas that 'have been done before' but to also address this functionality to be a true CUI based on what NT is and needed for NT, not a DOS clone, nor a *nix clone.

People jumping in and saying, MS should just do everything like a *nix shell is short sighted at the very least. WindowsNT is not a *nix, the input\output model is not the same, etc, etc.

WindowsNT also has the advantage of using the object models of NT in the new CUI that you don't have in the *nix world. It can be debated whether the 'complete' integration of most of the NT technologies is a good thing or not, but the fact is they are and because of this and the object model they are based on, MS was able to create a shell concept that works from this. In addition offer an interface to the shell for third party integration that works within the new Shell syntax through the object model of the applications installed on the Windows system. (Developers can allow CUI to their applications via these MS technologies by providing common object interfaces as they pretty much already do through the Windows GUI.)

In *nix such a concept is hard because of the fragmentation or the nature of the model of the average *nix OS. It is hard to create a common command line syntax that lets you administrate and control all the services, tools and applications. In the *nix world you end up editing configuration files scattered throughout the system for the various applications and services. (I know there are some efforts for unified models, but it isn't at the level of Windows especially when MS controls all of Windows.)

I personally would like to see more unification between the syntax on certain *nix platforms, leave in legacy as much as possible and where needed, but try to bring the syntaxes together. And this is happening, slowly over the past 25 years, but a bigger effort of a standard model should be explored for each *nix variant.

MS has always done well against *nix just because of this, even though the fragmentation of tools and

Re:Text

[bheer]

People like you should have been around in the early days of Linux where distros were installed off of floppy disks and WMs were usually crude

I was. I started off with Slackware in '94 (although I use Debian on the server and Ubuntu on the desktop these days). And Linux's install, hardware support+detection and boot manager may have been clunky but its command line was just as usable then (because it inherited from Unix) and was never as inelegant as its desktops are today. Unix command line tools fit together and has an elegance about it. The Linux desktop doesn't.

And what's worse, the problems with the Linux desktop have nothing to do with things that can be iteratively improved upon. They are more fundamental in that Linux distros use a "shovel in everything" approach to the desktop (which creates inconsistency and inelegance) and don't care about ABI compat which keeps commercial vendors out.

I'm going to summarize my point about desktop linux this way:

current_desktop_linux : future_successful_desktop_ linux ::
seamonkey : firefox

After a largely lacklustre Seamonkey, Firefox became successful because it respected its users and acknowledged that they needed to feel at home in their browser (right down to Tools|Options and File|Exit for Windows users). The usability team adopted a benevolent-dictator approach when dealing with L&F and kept the core UI clean.

That's the kind of attitude a successful Linux distro will have. I know a lot of the Gnome folk have a similar attitude, but all their hard work is undone* when an average user has to go out of Gnome to do anything (in my case I had to install kdebase for Konquerer's WebDAV support because Nautilus' WebDAV crashed with my HTTPSed WebDAV provider).

* Yes I know a desktop is fundamentally different from a browser, and that Windows has the same problems -- Microsoft cannot control fit and finish of 3rd party Windows apps. But Gnome with its much smaller market share obviously has to try harder instead of cribbing "MS does it too and gets a free pass".

> Average home users were more interested back in the day.

I agree, but we've to deal with the world as it is, not as we'd like it to be. When your competition offers fit and finish you had better do the same.

The relevant quote...

[joe_bruin]

Ahem:

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

Re:The relevant quote...

[Anonymous Coward]

Ahem:

History is written by the winner.

(Bash Unix on /.? Better anonymize for this ribbing!)

Re:The relevant quote...

[bod1988]

I belive they have. It's called linux.

Re:The relevant quote...

[shaitand]

Last I checked *nix is still winning ;)

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

[azote]

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

Please name thy author when quoting: Henry Spencer for this one...

Yeah yeah, call this "karma whoring", I don't GAF! ;-)

Re:The relevant quote...

[shaitand]

Perhaps you need to look at the bigger picture. The desktop is a battle, not the war.

Re:The relevant quote...

[swillden]

The big thing is- who wants to wait 4-5 seconds for their shell to launch?

Hey! Konsole isn't *that* bad! And isn't it worth the wait for all those nifty features?

Huh? Whuzzat? He's talking about something else?

Oh, sorry.

Re:The relevant quote...

[MichaelSmith]

I belive they have. It's called linux.

I have never heard Henry Spencer say that. If you have doubts you could always ask him what he thinks about Linux.

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

Re:The relevant quote...

[magetoo]

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

And those who do, invent Plan 9.

(Sorry for the off topic post, but someone had to say it.)

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.

Dynamic horizontal resizing!!!

[Anonymous Coward]

When will the Windows command line finally have this?

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.

- Oisin

Re:but but but

[archen]

You have to realize this is a fundamental differnce between windows and Unix. Windows consists of some huge peice of software with signifcant integration with most of the other parts. Unix is a collection of programs which allow you to chain them together in useful ways.

That makes traditional shells just about worthless in themselves on Windos. Go download zsh for windows and see for yourself. Nearly everything we do on Unix based systems is actually a small dedicated purpose program. Windows just isn't set up this way, nor does MS seem inclined to attempt this either. Not to say they couldn't do something like busybox with some magic tricks to get a similar result, but in the end they gave us interactive programming language (thus not "simple" - which is the real power of the shell).

Given that I think I'd rather just use ruby.

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?

Re:but but but

[just-a-stone]

if i remember correctly, microsoft's windows services for unix contain pdksh or some kind of a korn shell.

in comparison, i prefered zsh for windows othe bash from cygwin, but if the structure of your userland does not refrect parts of the operating system (/proc, /etc, unix sockets,...) a text shell is limited.

i prefer text shells too and the passing of objects plus indirect api access seems like a huge work around of crippled design to me, but it fits the windows way and could be more useful than a text-centric shell.

Re:but but but

[misleb]

Those tools don't do you a whole lot of good if the system you're working on isn't designed to be manipulated that way. I tried Cygwin for a short while and found it rather awkward (but still better than cmd.exe).

-matthew

Re:but but but

[x0n]

Sounds like you need Linux then. Welcome to the world of choices.

Re:but but but

[Gorshkov]

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

And yet 20 years later, shells are still here ........

There are only two possible conclusions:

a) people who have used shells are so stupid and/or brain-damaged that they can't do anything any other way

b) Sometimes, a shell really is a better tool for the job

I think I'm gonna go with Door #2 again ...........

Re:but but but

[hachete]

I thought that ssh was the answer to my questions about how to automatically update my buildtools on my small server farm. Between working out how to run password-less logins on cygwin ssh - which seemed to be broken on and off with new new version of cygwin - and the differing behaviours/bugs of successive generations of bash and ssh in cygwin, I gave up. Nice idea, but it seemed to be too unstable for words. If anyone knows any different, let me know.

Re:but but but

[sedyn]

I use Gnome, and I'm a terminal junkie (hell, I use the terminal too much in OS X). But I still use the GUI over 50% of the time. They both have their uses.

That being said, in the quote you highlighted I'm saying that we shouldn't dismiss something new, just because it's new. Nor because it comes from MS... I wasn't bashing shells.

Re:but but but

[barrkel]

The most important thing to do is use rxvt as your terminal, making sure you add some appropriate lines to your .Xdefaults file to customize it. It's far superior to the console window in Windows.

These days I live in bash on cygwin. Mount your C: drive on /c, and write a few wrapper utilties using cygstart and $(cygpath -w ), and you'll soon be in a much better place.

Re:but but but

[Gorshkov]

No, I'm not dismissing it at all - I was just trying to make the point that sometimes, a GUI is best .... and sometimes, a shell. That's why they're still around. Too many people seem to be of the opinion that if you use - or want - a shell, then you're some old fart who hasn't learned anything in 20 years.

I may be an old fart, but there's nothing brain-dead about me.

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?

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

Re:REXX? AppleScript?

[csoto]

LOL! Exactly the first thing that popped into my head - "hey, good thing they kept that OS/2 REXX code around..."

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.

[Anonymous Coward]

A "shell" is an interactive layer around the functions that the OS supplies. Because the user has to give commands and read outputs, the natural interface is text, but to programs serialization and deserialization is an expensive chore. Many interactions with a shell require several programs to work together. With an entirely text-based shell, this means a CPU hungry and error prone serialization-deserialization step for each connection between a pair of communicating programs. On the other hand a pure text interface allows for easy debugging and ad-hoc adaption. An object passing shell is first and foremost a performance boost in complex interactions and it also gives the benefits of self-describing data, i.e. no more trying to filter a single datum from a wad of text output with regular expressions. Think shell scripting, without the sluggishness and unreadability.

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.

[Anonymous Coward]

cygwin

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.

[iamdrscience]

Yep, nothing makes a program faster than adding a virtual machine and making everything an object!

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.

Re:i don't get it.

[marcosdumay]

My bet is that Microsoft doesn`t "belive" that text is usefull. Their culture is against text, mostly because it is easy to reverse engeneer written stuff.

And if speed is a concern on the scipts you are writting, you are really using the wrong tool for the job. Shell is for simple, hight level scripts.

Re:i don't get it.

[I'm Don Giovanni]

not only shipped separately, but bundled with the Exchange mail server only!

No, it'll also be available as a free download. Hell, the "article" that is the impetus of this thread is the download page for RC1.

Re:i don't get it.

[the hopthrisC]

This exact scenario is actually simpler in Powershell - check this blog entry http://blogs.msdn.com/powershell/archive/2006/04/2 5/583272.aspx

So what?

This blog entry only shows that the person writing the examples is either an incompetent shell user or has intentionally been looking for the most cumbersome way to do the given tasks in a unix shell.

Re:i don't get it.

[samael]

A text shell isn't any lower level than a GUI. Both are just ways of sending commands to the kernel and displaying the results (if any).

One is prettier and the other allows for complex chains of commands to be typed in, but neither is inherently more part of the OS itself.

Re:i don't get it.

[jawtheshark]

Windows already has a shell. It's called cmd.exe. It's the barebones method for user interaction with the OS

Yes, cmd.exe is a shell. Definately... Still, I don't think that I can interact with the whole OS just by using cmd.exe. I get along rather well with writing .cmd and .bat file, but sometimes one has to resort to multiple ones for doing the same task one could do with one script file in *nix.
Oh, and as far as I know, I can't interact with the registry by using the shell. (For example: delete a registry key). Regedit does have command line switches, but most stuff seems to go over .REG files. Well, perhaps it can be done, but I don't know how and I didn't find much in the Windows Help files. The registry is 100% part of the OS, so it should be accesible by using the integrated shell (which is cmd.exe).
At least I found out about cacls, which is very useful on Windows XP Home machines (that have "limited users" and some badly-behaving applications)

Re:i don't get it.

[pimpimpim]

This guy should subscribe to the "useless use of grep" user group, if it existed :)

But ok, let's be fair, there is the advantage that you won't get funny output for example, for the first row where columns contain text instead of numbers. You won't get errors and everything will be executed neatly, for the shown examples that works well. But even then, I have the impression that you loose a lot of flexibility! What if you want to output stuff to a file, with a certain string around it? What if you want to call a program does not belong to the standard set of predefined macros? And what if you want to add options to the call that program?

Re:i don't get it.

[pimpimpim]

actually that the shell is shipped separately is not very odd, you can install csh,bash,zsh,ksh,tcsh, or whatever, seperately on your linux OS :) I'm contemplating if you could also install linux without a shell, but I guess there's not much left to interact with then ;)

Re:i don't get it.

[jawtheshark]

Thanks! Exactly what I was looking for... I wonder how I overlooked it in the "Command Line Reference". Very helpful!
So, this makes cmd.exe pretty much a full featured shell, even if many people won't accept that fact :-)

Re:i don't get it.

[ecuador_gr]

Am I missing something? Are you talking about Mac OS X maybe? Who modded this up? I might be living in a different world, but most useful open source programs come in windows versions anyway, and in some categories (multimedia mostly) they even come ONLY in windows (VirtualDub anyone?). And the plethora of supplemental tools that come with a Linux distro are of course not a feature of the operating system, just a matter of bundling. The funny thing is that if MS tries to bundle things (like the - sucky - Media Player), they will get sued for using their monopoly to destroy the competition (sometimes horrid competition like RealPlayer etc). And I will not understand any objection about downloading free software that does not come with windows. Don't you download your Linux distro anyway? Or just because apt-get is so great and seamless we don't consider that "downloading" of tools? Anyway, I mentioned Mac OS X at the top because there you have the prime example of selling a stripped kernel (compared to a usual Linux kernel) and then make you pay for obvious features (whaaat? you want cross-platform networking? pay!). Excuse the rant.

Re:i don't get it.

[ecuador_gr]

Woops, and excuse the missing html tags...

Re:i don't get it.

[omicronish]

The danm OS doesn't even come with a compiler

Windows 2003 comes with .NET Framework 1.1 installed, and I believe XP SP2 comes with .NET as well. You can also freely download and install both .NET Framework 1.1 and 2.0. And guess what? They both come with C#, VB.NET, and J# compilers. The 2.0 Framework also includes MSBuild, which can compile VS 2005 projects without installing VS 2005. VS 2005 Express was recently made free forever.

So while earlier versions of Windows didn't come with a compiler, that changed with 2003 and Vista, and now you can also download a free IDE.

Re:i don't get it.

[mckyj57]

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.


You sort of have a point, but...

1) 95% is a number you made up. It is nowhere near that.

2) How easily are the tools found and installed, and how robust are they?
There is no comparison with the distribution mechanism and ease of
installation on Linux. I know some provide fine self-installers, but
some don't.

3) Rarely do they have source you can easily compile.

Free and open source Windows tools are a hodgepodge, and it is major
work hunting them down in many cases. Often they are crippled,
particularly if they require a service/daemon. If you use a service like
TUCOWS, sorting the FOSS ones from the shareware ones is also difficult.

Sometimes you can't tell if you need a tool until after you have tried it. The
shareware process is flawed in a lot of cases, and I have spent thousands
of dollars on windows utilities that I have hardly used (not for myself, for
my clients systems).

Re:i don't get it.

[kchrist]

I mentioned Mac OS X at the top because there you have the prime example of selling a stripped kernel (compared to a usual Linux kernel) and then make you pay for obvious features (whaaat? you want cross-platform networking? pay!).

Can you give one example of this, having to pay for "cross-platform networking" (and also an explanation of what you actually mean by this). Have you ever actually used OS X?

Keeping to the original point, note that every OS X system includes, for no extra cost, a number of standard Unix shells and not only gcc but Xcode.

Re:i don't get it.

[nuzak]

> 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

Pico runs just fine on windows. Compiled it with gcc, which also works fine. You're a walking bucket-o-ignorance, fella. About the only thing lacking for windows is apt or an equivalent.

Re:i don't get it.

[ecuador_gr]

Oh, boy, I forgot about the Mac zealots! I thought after the move to x86 they went away :)

Just kidding it is of course logical that you ask, since I didn't clarify.

While I was a grad student I worked as tech support at a large NY university. In my department we had 120+ windows machines (administration - of course in all our CS labs Linux & Solaris is the norm), various wireless devices (Win Mobile or Blackberries), and about 5 Macs and a couple Linux machines. Our 3 person team took care of all these - except the Macs. Whenever the Mac users needed something that could not be done by someone proficient in just Linux & Windows, we called the Mac people from the university central support dept.

I am babbling again, but to get to the point every time we had to pay for things that were included in Windows or even in Linux. The most prominent example was around $150 for each machine to see the NT network (DAVE).

Hope I didn't offend anyone! ;)

Re:i don't get it.

[Cal Paterson]

Parent: "There isn't a free C/C++ compiler to use to compile my favourite programs on Win32."

You: "We have C#, J# and VB!"

Few people wh have used unix are willing to put up with any of these closed languages. They want a C/C++ compiler. They might want Ada. Microsoft provides none of these free. None of their compilers work on other operating systems. None of their languages work on other systems. See the problem?

Re:i don't get it.

[omicronish]

Visual C++ Express is free. The C++ compiler itself (not the IDE) has been free for even longer.

Re:i don't get it.

[Cal Paterson]

This is related to unix; I'm talking about Free Software. Downloadable binaries aren't the same.

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]

And couldn't I just write this in C#? I don't get it.

Re:More like WMIScript

[tgd]

To be fair, its pretty trivial to create strongly typed WMI proxy classes. There's a command line to do it, or you can do it from code.

Just create a strongly typed proxy and use that, much easier. If you haven't done WMI before, you'd be suprised how rich of a mechanism it is for doing just about anything you'd want in a Windows environment.

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

[xarak]

kind of like:

get-objects -class | while read day dow hour ms min mo qu se wim yr
do
    echo "Day: " $day
    echo "Day Of Week: " $dow
    echo "Hour: " $hour
    echo "Milliseconds: " $ms
    echo "Minute: " $min
    echo "Month: " $mo
    echo "Quarter: " $qu
    echo "Second: " $se
    echo "Week In Month: " $wim
    echo "Year: " $yr
    echo ""
done

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

[cerberusss]

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

This reminds me of a discussion between a Dutch and a Russian developer about a protocol. Also present in the room is a Russian scientist, working on the same project.

Dutch Developer: "If you put 1 in this sequence field, the answer will be 1. If you put 2, the answer will be 2."
Russian Developer: "OK."
Scientist turns to developers: "That's unbelievable!"

Re:More like WMIScript

[ratboy666]

Bruce

I have been curious about this design in a shell environment. Do the objects not have serialize to text and generate from text methods?

If this is not supplied, it weakens the "debuggability" of the underlying OOP system. If it is supplied, the methods do not have to be supplied; they are then a standard part. (and I believe that it is -- as witnessed by your recoding of the example).

Given that the domain of the script code is itself text, it makes sense to manipulate at a textual level. The standard posix shell is more concerned with macro expansion than programming and integration concepts.

The object access will then always look a bit kludged (script code will rarely ITSELF be OOP), and any macro facilities will be strange to OOP programmers.

More insight into the "why" of this new shell would be welcome.

Ratboy

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.

Re:How much will it cost?

[hmallett]

This is Slashdot. You're not supposed to actually click on the links in the article...

Stereo-typical rhetoric[sic]?

[IHSW]

Where do you see ANY indication that this will cost you $? For god's sake, can we please stop the nonsensical MS bashing?

Re:Stereo-typical rhetoric[sic]?

[donarb]

For god's sake, can we please stop the nonsensical MS bashing?

Yes, from now on only sensical MS bashing will be allowed!!!

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.

Re:See! they admitted it!

[shaitand]

Riiiight, hell has been functioning properly for millions of years without a single crash. How can you claim it runs on windows with a straight face? Now if you were to claim that to be in hell is to be forced to use windows you might be on to something.

Re:See! they admitted it!

[bennomatic]

This reminds me of an ad campaign for Lake Tahoe. They were really pushing to get people from relatively nearby areas (ie the SF Bay) to go there, and they had a site called GoTahoe.com that they pushed on all the busses and trains in the area.

Of course, that ad campaign--although not the site--were pulled not long after people started referring to it in common parlance as "Got-A-Hoe dot com".

Of course, I don't know if the site was sponsored by the California side of Tahoe, or the Nevada side, where the alternate name could be accurate.

Re:See! they admitted it!

[schnits0r]

Hey, I went there once, I thought it was a grdening site :(

Re:How much will it cost?

[cnettel]

I didn't :-)

Clippy?

[MightyMait]

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

Re:How much will it cost?

[n0dna]

Shame you didn't RTFA, you'd look smarter.

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:Strains the definition of "shell", kinda

[kestasjk]

We all know there are other scripting languages already out there, but PSH integrates into Windows, that's why it's been created.

Good name change!

[m4c north]

Monad...

Is that like a gonad, but you only have one? And I thought eunuchs had it tough!

Re:Good name change!

[That's Unpossible!]

This was hilarious the first 1000 times I saw it posted under previous Monad stories.

It's especially lame making fun of a name that has already been changed.

Re:Good name change!

[ragingmime]

Actually, it's a Greek word that means "unique," "one," or "God." Which is strange, because it doesn't sound like it's unique, it isn't one with the rest of the Windows OS, and it certainly isn't God (unless Mr. Gates has been having some delusions of grandeur lately).

Re:Good name change!

[basshedz2]

Its also the term that Gottfried Wilhelm Leibniz used in his metaphysical philosophy. Leibniz used the term Monad to refer to the smallest building blocks of nature. They are roughly equivalent to atoms in the physical world, however they are also equivalent to souls in the metaphysical world.

For a translation of Leibniz's Monadology, clicky.

+1 Truth

[Anonymous Coward]

If you think bash is a good language because you can embed perl into it, you seriously need to back away from the xterm and get some fresh air.

Re:+1 Truth

[tomstdenis]

um ... for the bulk of my automated tasks I use perl and bash. I use perl for more "constructed" solutions and bash for the more automated ops (e.g. list of commands). Seems to work fine for my projects where I have to navigate random directories and what not.

Tom

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:What about the applications?

[Excelsior]

Yes, do pipe to your heart's content.

cat comment|grammar-checker|spell-checker

Re:What about the applications?

[miffo.swe]

Well sorry about that, im swedish. Please do point out what i spelled wrong or how i should have made up my sentences.

Re:What about the applications?

[Excelsior]

Actually, I didn't realize that because your English is quite good. You don't need to be sorry. I was just trying to make a geeky wisecrack.

But, since you asked, I'll be constructive.

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.

1) This is a run-on sentence (more than one sentence strung together). Better to break it up "...shell in mind? Or is this..."
2) It is a question (or at least part is) but ends in a period.
3) "hearts content" is posessive, so should read "heart's content"

I have also a hard time imaging using objects being easier to understand for normal admins and users.
1) "have also" - Although it is completely acceptable the way you wrote it, typically a native English writer would write "also have".
2) "imaging" should be "imagining".

Also, when exactly did the shell stop to suck and begin to be a good feture? The same second Microsoft made their own version?
1) "stop to suck" - a native writer would write "stop sucking"
2) "feture" should be "feature"

But, as I said before, you're English is quite good as a second language, and far, far better than my Swedish. So forgive my insensitive wisecrack.

Re:What about the applications?

[marcosdumay]

I doubt the applications will interact well with the shell. It seems that there are some "anchors" on .NET normal programs that could be called by it. I am not a .NET programmer, so I don`t know what really are those "anchors", but I doubt they will be published. Teoreticaly, you could also use shared libraries on your script, but I didn`t touch Windows since MS released the first versions of this, so I simply don`t know if it does that.

Anyway, the applications will not interact well with the shell because they aren`t free. Since they aren`t free (beer), you can`t expect people to have them. That means that the equivalent of the specialized (sed, awk, perl, make...) hackers that live well on the Linux shells won`t be able to translate their knowledge from system to system, it also means that there will be no portable complex script. Since they aren`t free (speech), you have no way to be sure that the programs will export an usefull interface, and that interface will continue being supported when the time passes. It is even worse when you think about standard interfaces, like the ones that exists on some subsets of common free OSes commands.

So, even if Microsoft really wanted to give the admins a good experience and had competence to do that (two very big IFs), they couldn`t. It is simply not on their power.

Re:What about the applications?

[shish]

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

listusers | print user.name

cat /etc/passwd | awk -F: '{ print $1 }'

(A demonstration of how if could be easier, I don't know if it actually works like that~)

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.

Re:Vista: Includes Free RootKit!

[shaitand]

The parent is a technical question about the newly released technical solution that the slashdot story refers to. What variety of crack is so powerful that ANY mod could have possibly considered the parent post offtopic????!!!

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)

[RzUpAnmsCwrds]

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.

There's your problem right there. String parsing is neither easy nor robust. When you have executables that each output data in their own format, how do you find a simple, robust way to work with that output? That's what PowerShell is all about - you don't have to parse text files because data isn't presented as plaintext.

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

Re:I've tried PowerShell (formerly Monad)

[eman1961]

But the problem is, sometimes you HAVE to. As an example, I sometimes work in a huge documentation system that uses GUIDs to tag samples, and the docs are stored as XML files, and you have to grep and find the file that contains the sample, create a list of the corresponding docs and snippets, and process the snippets in a particular way, then submit a text file back to the doc system. I don't have a choice about my sources or the format of the file that I have to submit. So, I have to process text files, and Monad didn't help.

Re:I've tried PowerShell (formerly Monad)

[Westley]

If the docs are stored as XML files, then I suspect Monad would make things a *lot* more robust - you could load the XML files up *as XML documents* then use your favourite navigation technology (XPath, XQuery, whatever) to find the nodes you wanted. The only bits which need to use plain text are the first and last ones, and they can be done easily using the .NET framework.

Now, maybe it isn't obvious exactly how you do all those bits - but I suspect if you gave someone bash and only told them as much as you know about Monad, they wouldn't find it obvious how you do the above task either.

Jon

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:Linux is posix

[mindstormpt]

Windows is also POSIX1 compliant. Does that make it a UNIX implementation? Linux is a reinvention of UNIX, at least in the sense the grandparent that the grandparent meant. It might implement some interfaces/behaviour, and it is great, but it just isn't unix.

(For the record, I'm not in any way agins linux or any other OS. I use WinXP, Ubuntu and OpenBSD at home and like all of them).

Re:Linux is posix

[swissmonkey]

1) On Windows you can have the shell of your choice, and this download is a proof, it's a _download_, hence an additional shell you can choose to install or not, or use another one
2) You can use the language of your choice with bash ? How can you write a bash script in C++ ? I was never was able to do that.

As for Windows fumbling around with basic lessons, my guess is that, like the shells, you've no clue about Windows internals and architecture.

Hint: the people who designed the architecture of the NT line were behind VMS, they really don't need people like you to explain them basics of OS design, nor do they need help from Unix people.

Re:Linux is posix

[Jugalator]

No, linux is an implementation of Unix, not a reinvention of it. It's POSIX-compliant.

Hehe.. Well.. http://www.microsoft.com/technet/archive/ntwrkstn/ reskit/poscomp.mspx?mfr=true

Re:Linux is posix

[amRadioHed]

You can't write a bash script in C++, that's not what he was saying. He was saying in Unix by default you can choose from several interactive shells as well as several different programming and scripting languages. This is quite unlike the Windows approach.

Re:Linux is posix

[amRadioHed]

Also, regarding VMS. VMS is a rock solid OS, but still from what I know, it isn't nearly as flexible as Unix. Personally I don't like DCL at all.

Re:Linux is posix

[Cyno]

But anyway, Linux isn't a reimplementation of UNIX, that's GNU. And GNU's not UNIX. Its more like innovation on top of the old UNIX design pricipals, merging Plan 9, Windows, Novell, Apple, *BSD with UNIX.. independantly nothing new, but when its all put together into a GNU system its like nothing else.

Re:Linux is posix

[GnuDiff]

Hint: the people who designed the architecture of the NT line were behind VMS, they really don't need people like you to explain them basics of OS design, nor do they need help from Unix people.
--

Does the word "monolithic" figure anywhere?

Re:Linux is posix

[WWWWolf]

Linux does adhere to the POSIX standard. Linus has seen the specification, I hear. RMS has seen the specification and liked it so much that, in throes of passion, named one environment variable POSIX_ME_HARDER. The kernel and the GNU C library and userstuff both implement what's a reasonable user environment, with a specific POSIX compliance mode (POSIXLY_CORRECT, the latter spelling of the aforementioned variable) for things that don't really make much sense from user perspective but the standards want them.

Now here's one catch that the pushers of "open" (open as in "The Open Group", not open as in "Open Source") standards tend to do: The specs are free (or at least available if you show the standards body some money), everyone's free to implement the thing, but the real money sink are the conformance testing and trademark use rights (which usually imply the conformance has been taken care of). Ask anyone who has tried to implement Java! POSIX and Unix system specifications are the same.

And as pointed out, the POSIX certification of at least one Linux distribution has been taken care of, which means that if you really care about the standards adherence, you can get yours tested too and it will likely pass just fine.

And Microsoft's approach to POSIX is a bit different: They only implemented what's absolutely necessary and don't have any ambitions of going beyond that. Just sitting in front of a WinXP system without knowing anything beyond "yes, Windows does POSIX" would get me a rude surprise. "Where's my Bourne shell?" "Well, actually we only implemented the bare-minimum POSIX C API" "All right, where's my frigging C compiler?" "Er..." You need to Download Something to get any real work done.

Re:Linux is posix

[CarpetShark]

Well, no one is going to reimplement something exactly when they want it for new things. That would be an emulator or a clone, not a fresh implementation. This applies moreso than usual in Unix, where the operating system definition is relatively flexible. The GNU vs. Linux terminology isn't as relevant here as you think either. Two months before Linux 0.01 was announced, Linus posted the following:

"Due to a project I'm working on (in minix), I'm interested in the posix standard definition."

That project WAS Linux, so he definitely had POSIX in mind in his implementation. No unix kernel is going to implement the entirety of POSIX, but no one would expect it to.

Re:Linux is posix

[Cyno]

While Linux has little or nothing to do with UNIX, GNU does, even though it has expanded that definition to include a lot of other protocols and concepts. But what the hell is UNIX anyway? Is it all those old memes like "everything is a file" or is it C or the shell or what?

It used to be UNIX and C, or etc. But now I just think of it as a collection of concepts that evolve over time. UNIX is getting more LinuxOS-like, IMO, because of the competition of a non-tradition/free-thinking open implementation.

Re:Linux is posix

[userlame]

2) You can use the language of your choice with bash ? How can you write a bash script in C++ ? I was never was able to do that.

Perhaps this isn't what you meant...

#include <iostream>
#include <fstream>

using std::cout;
using std::cin;
using std::ofstream;

int main() {
char script[] = "echo 'poop';";
ofstream fout("/tmp/bash.yay");
fout << script;
fout.close();
system("bash /tmp/bash.yay");
cout << "Ta-da.\n";
}

...but I was bored anyway.

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

[Lando]

Thanks for the reply, however section 2 is the one that I am worried about. From the site:

2. How and When You May Use the Passport Network.

We will provide you with credentials on the Passport Network to use with the Passport Network. We provide the Passport Network for your personal use. You may not use the Passport Network for commercial purposes or in a way that is against the law. You may not use any software or hardware that reduces the number of users directly accessing or using the Passport Network (sometimes called "multiplexing" or "pooling" software or hardware). You also may not use it in a way that harms us or our affiliates, resellers, distributors, service providers and/or suppliers (collectively, the "Microsoft Parties"), or any customer of a Microsoft Party. We may tell you about certain specific harmful uses in a code of conduct or other notice available through the Passport Network. We have, however, no duty to do so. You will obey any codes of conduct or other notices we provide.

If you wish to offer the Passport Network to users of your own application, Web site, or Web service, then you must enter into a different contract with Microsoft.

From this statement, if I look at the way their code works and I use that knowledge anywhere else, then I may be "harming" Microsoft or it's affiliates. I don't know what they would consider harm.

Re:Downloading

[Seraphim_72]

I think what they are trying to get at is that you may not use some software of your own creation to use the Passport Network to harm MS or it's affliates. Essentially, if you sign up and see a flaw you can't exploit it.

Sera

Extensions...

[d3matt]

From TFA:

Designed for extensibility so that independent software vendors and enterprise developers can easily build custom tools and utilities to administer their software.

Looks like it might not be that hard to create a bash wrapper or similar (python anyone?)

Re:It's not cost.... It's not a Re-invention

[PitaBred]

Yeah. The script kiddies want to manage your code. Duh.

or python

[Xtifr]

In this case, it sounds more like "those who do not understand Python".

Note, Python seems like a more appropriate comparison than Perl, because Python is interactive, while Perl is not, unless you do some funny ad-hackery. Although Perl does have that arbitary-kluginess that fits better with what I'd expect to see from MS. Actually, though, I would kind of like to see this system before passing judgement. Unfortunately, MS seems uninterested in supporting any platforms I'm willing to run, so that may take a while.

Re:or python

[jrockway]

> funny ad-hackery

like perl -ne 'print eval';?

Yeah, what a hack. I hate those one-liners :)

example of this shell in use:


> 2+2
4
> use YAML; Dump({x => 10, y => 20});
---
x: 2
y: 3
> use LWP::Simple; get "http://slashdot.org/"
[[text of slashdot.org]]


Definitely completely useless and a total hack. I'm sure Perl (and the CPAN) will be immediately abandoned by everyone in favor of MSH or Python :)

Re:or python

[chthon]

Just do :

perl -de 1

And you are in the debugger where you can do interactive stuff.

Re:The relevant quote... [Apple is NeXT with...]

[tyrione]

An Apple brand. It shouldn't surprise people that they know UNIX and Objects. Unfortunately, NAppleXT has spent an awful lot of time making that legacy happy. Let's hope this diminishes greatly with Leopard.

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

[CRC'99]

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

Yet I bet it still only takes a single nail to make the whole thing useless :|

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:And the point is?

[gregarican]

Third, I can do a lot of administrative programming for Windows in Perl. I imagine python and ruby have similar hooks (haven't checked).

The answer is definitely. Python and Ruby makes the ugly clumsiness of Perl look like the difference between test driving a Cadillac Catera and a Lambourghini Diablo. I have coded in all three and when I picked up Perl code I wrote a couple of years ago it felt like I was trying to decipher the Dead Sea Scrolls.

Using either Python or Ruby I would say I cut about 75% of my admin brain dead tasks down to scheduled jobs.

Re:.Net rocks

[IntergalacticWalrus]

Bash or Perl? How about comparing C# to something that's actually in the same league, ie. Java?

Hey, I'm a unix fiend...

[comingstorm]

and I haven't actually used the new shell. But from what I've read about it, Monad is something I've been looking for for years, in a shell.

Basically, shell programming sucks. And I say this as someone who has to do a lot of it, for a living. You can work with it, but it's awkward, and error-prone, and fragile because everything has to be passed as an friggin' untyped text stream. Yes, text streams are simple, and to their credit, they do allow Unix tools to work together, kinda. And everyone knows that suckage is relative; you're brilliant as long as everything else sucks worse.

But, the *right* way to pipe data is to pass streams of objects; if you have a set of tools can do that, they will suck less. It is of course unfortunate that Monad is tied to such a proprietary platform...

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.

Text formats dead...

[SuperKendall]

They get that *nix's text based communication is a crude and outdated way of doing things

You might want to tell that to the people doing SOAP. I think there may even be a few at Microsoft.

Why not pure XML communication between programs in a shell? Then it's fully backwards compatible with older text-oriented utlities.

Of course, perhaps they are serializing the objects between processes in just this way, I have not looked at the details.

Re:Text formats dead...

[PsychicX]

It wouldn't surprise me at all if they were internally serializing to SOAP to do the actual communication. There's a SOAP serializer built into the class library; it'd be a really easy way of implementing it.

Re:Text formats dead...

[Chokolad]

> Why not pure XML communication between programs in a shell? Then it's fully backwards compatible with older text-oriented utlities.

By default it is objects, but there is Xml formatter as well which you can insert into pipeline and get XML if you need it.

Re:Name

[Ithika]

Everyone knows the name "monad" gets deprecated after a while because no-one's manly enough to use them as they are. And the Microsoft culture had a built-in aversion to going to with the "warm fuzzy thing" name, despite there being precedent.

Sigh.

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

[miffo.swe]

And how, from the users perspective, is this better than bash? What can i do with this i cant do with *nix today? Are all the various Windows applications and admin tools in some magic way now "shell aware"?

As i understand it this wont work with old apps but only new ones with support built in by the developers. I also assume this shell will have to go through the same process as the *nix shell in weeding out the security holes and bugs. Or do you really assume this is released with zero bugs from day one?

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

[Anonymous Coward]

Its also worth mentioning the old blog, since the new one is several hours old.

http://blogs.msdn.com/monad/

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

[cgranade]

I must admit that I hold no love whatsoever for your company, but this project is one of the most creative things I've ever seen to come out of Microsoft. Personally, this shell was the one feature of Vista that I was looking forward to.

Re:Come kick the tires

[anominous]

Well, depite the deluge of abuse that your likely to incur - I, for one, (no, not that old gag) - would like to thank you for sharing. Cheers.

Re:Come kick the tires

[SuperMog2002]

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

Hehe, pretty yet functional GUI with full featured bash one click away is one of the main reasons I dumped Windows!

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:Come kick the tires

[I'm Don Giovanni]

"OK, I could have expressed my point more profesionally without the snide attitude."

Somehow, I doubt that.

Re:Come kick the tires

[I'm Don Giovanni]

An Anon posted the link to the interview, not a Microsoft guy (as far as we know). So you were an arrogant ass for no reason at all.

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

[grcumb]

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

Yep, and the brakes will ship in the second service pack. 8^)

Re:.Net rocks

[Procyon101]

Why does .NET kick ass? I program in C# daily. It is Java, redone decently, with a couple extra features but without some of the polish that Java has. It's nice for a scripted language, but it's by no means revolutionary. Hell, Java isn't revolutionary. .NET is another iteration of a concept that has been around since the 70's, and it has the same advantages and disadvantages that all VMs have. Nothing much to see here. Give me a reason why it's the dog's bollocks, because I really am curious.

Re:.Net rocks

[Aladrin]

You write shell scripts in Java? Are you INSANE!?

IronPython

[pOrATa paTima]

Things would just rock when combined with IronPython. You could easily create something like Monad/PowerShell with IronPython, which fully integrates with .Net. Heck you can even use VisualStudio to edit/debug your scripts.

Install SFU

[Philip K Dickhead]

Or whatever it is renamed!

In Vista, it will ship as a regular component of the Pro and Enterprise versions.

http://www.microsoft.com/technet/interopmigration/ unix/sfu/default.mspx

http://www.microsoft.com/downloads/details.aspx?Fa milyID=896c9688-601b-44f1-81a4-02878ff11778&Displa yLang=en

Get Bash, OpenSSH, BSD pkg_tools and the GNU toolchain here:
http://www.interopsystems.com/tools/warehouse.htm

Oh, and if you want MS's fast compiler, as opposed to GNU's portable one - then this is free. Add an environment variable, and cc calls this:
http://msdn.microsoft.com/vstudio/express/visualC/ default.aspx

Re:Install SFU

[tomstdenis]

Should point out that while MSVC is faster than GCC it isn't better. GCC supports more platforms [e.g. code you write with GNU tools has a better chance of working elsewhere, provided you're not using the w32api], has better optimizer algorithms and adheres better to the ISO specs for C and C++.

You sacrifice a lot to "just build quickly".

Tom

Re:Install SFU

[flakier]

GCC isn't all that (but it isn't the worst either). It takes more than running on multiple platforms to make something good. In fact, many people a lot more knowledgable than I would say that's a bad thing. :)

http://lists.cse.psu.edu/archives/9fans/2006-April /046972.html

The venerable and late C/C++ users journel had a compiler shootout not too long ago and to my recollection GCC was squarely in the middle to lower end of the pack. The microsoft products weren't always first in every test but they placed well against the likes of Borland

Just to try and steer this back on topic I'll point out the Channel9 site on MSH/Monad/PowerShell http://channel9.msdn.com/wiki/default.aspx/Channel 9.MSHWiki It's a really great reasource for finding out about what this thing is all about. I have to say I was skeptical for a long while since I tried out the first beta (but didn't really dig in). After seeing some examples (check out the Jeffery Snover videos) I was suitably impressed. Impressed enough that I'd like to see something like it on Unixy things. Like others have said, if only there were a decent native terminal *sigh*

Re:Install SFU

[tomstdenis]

512KB for a hello world app?

I copied that source code and ran it through

gcc -O2 test.c -o test -s

And the resulting binary is exactly 5,624 bytes with GCC 3.4.6-r1 on an AMD64 Gentoo box. Oh... I see he used -static ... he's a moron.

What's better, 30 apps loaded with their own copy of libc or 30 apps loaded with one copy of libc. Shared objects exist for a reason.

That would be like appending the .NET VM to every application you write for .NET. I'm sure the 20MB or so of .NET you download for every hello world app would dominate by comparison.

This is what happens when you use mailing lists and random benchmark sites as authorative sources of information.

I work with MSVC and GCC fairly often and it has always been my experience that the code produced by GCC is faster. Specially when the code involves more complicated code structure like loops and pointer arithmetic.

Tom

Re:Install SFU

[chthon]

This reminds me of Acucobol on HP/UX.

A couple of years ago I was part of a migration from WANG VS to HP/UX + Oracle + Acucobol.

When we started compiling applications, I was shocked by their size, over 80 MB. After some browsing through the manuals I found out where the libraries were located and and how to use them with HP/UX ld.

The COBOL runtime dynamic library was almost 80 MB in size. By creating a makefile which which did the linking always dynamically, we ended up with executables between 100kB and 500 kB, which of course also started much faster (especially when using the preload option, which resolved library entry points without running the program).

In short, dynamic libraries optimise several things :

• They can reduce the size of your programs greatly, programs take up less space and load faster.
• Once a dynamic library is in memory, there is no need for disk access anymore, thus also faster loading times on programs.

Should all our COBOL programs have to run with a statically linked runtime of 80 MB, when running different programs, you exhaust your memory with code which is not very efficient.

10 programs x 80 MB = 800 MB, however, 10 programs with an average size of 300kB = 3 MB + 80 MB runtime, is 83 MB, this means that the first system has only 10% the efficiency of the second system.

Unifix Linux is POSIX.1 certified

[tepples]

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.

At least one distribution of the GNU/Linux system, called Unifix Linux, has been certified as conforming to POSIX.1.

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.

UNIX is a brand

[tepples]

It might implement some interfaces/behaviour, and it is great, but it just isn't unix.

Neither is the PlayStation a "Nintendo". UNIX is a brand. Or are there material parts of the Single UNIX Spec that you're wishing would be implemented in Linux?

This thread is useless without screen shots

[Bushido Hacks]

Not to be a heckler or anything, but I'm not convinced. I would at least like to see some screen shots before I give it a try. Secondly, what is this? An object-oriented shell? I'm a computer science student and all pro-Linux, but I would still like to know more information about this shell.

Re:This thread is useless without screen shots

[Bushido Hacks]

Duh! I know what a CLI is. I want to see what it looks like. What happens when I type something like dir or cd \ Are thier any feature? If I right click on the window, what will the menu look like (even xterm has something like that).

Just enlighten me.

.NET supports numerous languages

[tepples]

in Unix by default you can choose from several interactive shells as well as several different programming and scripting languages. This is quite unlike the Windows approach.

O rly? The .NET framework supports numerous languages: C#, C++ with Managed Extensions, Visual Basic, J#, Perl, Pascal, Forth, Eiffel, ML, and more.

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

[sl4shd0rk]

I don't recall too many things microsoft has added 'spokes and rubber' to that didn't end up causing a train wreck.

Roaming profiles
nice idea. Home directories that travel. Watch 20 users save everything to their desktop for about a month- train wreck.

Active directory.
Have fun mixing your nt domain controller with your 2000 ad box.
While your at it, don't forget to use those underscores - what, DNS? whoops!- train wreck.

Internet explorer
A web browser for windows. What a neat product. Let's give it the ability to install operating system software over the internet- train wreck.

Face it. Microsoft has been saying things will get fixed with the next version since windows 95. They've not delivered on that yet as far as I can tell. More features get added, but nothing gets fixed, and the reason is because it makes for good marketing. People keep waiting though, and hoping, and spending, and that's all that counts when marketing is your drive.

It's so bad

[tepples]

If the quality of this product matches the quality of Microsoft's other 1.0 products, then "It's so bad" is about right.

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.

Re:.Net rocks

[IntergalacticWalrus]

My point exactly. He was comparing things that don't filful the same goals.

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

Re:Quick resize

[x0n]

Holy crap, that was buried in the back of my head from dos 2/3 days ; I forgot about that old chestnut. I never would have thought it was carried through to NT. Nice one!

- Oisin

"Power" Shell? Microsoft is a bit late...

[R3d M3rcury]

Apple is already dropping the "Power" nomenclature (ie, PowerBooks became MacBooks). Redmond's photocopier is too slow. :^)

Not compatible with Windows 2000

[tepples]

Where do you see ANY indication that this will cost you $?

"System requirements: Windows XP or later". A lot of Slashdot readers still use computers purchased before January 2002, when PCs started coming preloaded with Windows XP. They would have to shell out a not insignificant amount of money to upgrade to Windows XP (for desktop machines) or Windows Server 2003 (for servers). See thetoastman's comment to this article.

PS? Shouldn't it be PSH?

[foorilious]

Pronounced "PSSSSH!" of course.

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

Re:.Net rocks

[glenstar]

This appears to be a translation error between British English and American English. What the OP said was "It's the cat's ass" and you heard that as "the dog's bollocks". Unfortunately this mistranslation does not work because C# is the cat's ass whereas java is the dog's bollocks... neither of which are to be confused with python being the snake's bowels or ruby being the snow monkey's larynx. Perl, of course, is the camel's penis and VB is the sea slug's rectum.

I hope that helps.

cygwin & rxvt

[kybred]

You might look into Cygwin and rxvt.

Re:Name

[grondu]

...so people don't call it NoNads?

Re:.Net rocks

[Billly Gates]

There is the beanshell.

I have never used it but I think it came with Forte and Netbeans in earlier version in some sort of java desktop(not gnome). My guess is the desktop and beanshell terminal were part of the failed JavaOS that was ported to the javavm from sun engineers who missed it.

After playing with StringBuilder and the various string classes in java.utils, I thank god I don't have to write any shell scripts in java! What a mess and I feel sorry for companies like Catapiller who write scripts in c++ instead of shell scripting in order to follow standards on one langauge. I dont hate java but string handling is not its strong point compared to other languages.

or lisp

[Slithe]

Most lisp implementations are interactive. Also, a lot of features from modern scripting languages seem to be a knock-off of lisp features. Python is a good example with its (soon to be removed) lambda functions.

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.

Re:The other PowerShell

[Dr. Sp0ng]

Wow, you still use it? Does it still work with modern distributions?

(I wrote PowerShell, haven't updated it in years though - not since gnome-terminal got tabs)

The most important question

[Antimatter3009]

Can I use ls to get a file listing yet?

Re:The most important question

[eMartin]

Yes, but the extra options don't work.

In fact, it's the same as the dir command.

But then, the extra options for dir don't work either.

What's weird is that they've also decided to make options start with the - instead of the /, but instead of offering both, or some kind of backwards compatibility, you need to learn all new options for the common commands.

Of course, you need to know that the default help command is now -? instead of /?.

And then, the help for most commands is now several pages long, instead of just a listing of options and what they do.

Re:The most important question

[maxume]

If you actually use windows and want ls(among other things), check out:

http://unxutils.sourceforge.net/

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

[x0n]

Touché; however, that analogy would still apply to all wheels [shells] ...

i dont like it

[tscheez]

sorry. (wait, it's microsoft, why am i apologizing?)

first it's slow. slower than it takes cygwin to load. second, it's too much typing. all the short form aliases are nice, but seriously, remove-item for rm? maybe it's just me, maybe it'll grow on me, but i doubt it. plus, they really should do a google search before coming up with names, the first result for powershell is http://powershell.sourceforge.net/ (the thought did cross my mind)

Re:i dont like it

[multi io]

plus, they really should do a google search before coming up with names

They did -- and then chose that name deliberately to hurt some innocent Open Source project :-)

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

It's all in the name..

[solcity]

One wonders why they chose to change the name... the open source/gnu movement would have called their copy Gonad!

Re:.Net rocks

[OverlordQ]

It's Perl the language, or perl the interpreter, there is no PERL, it's not an acronym.

That's the terminal...

[Corngood]

You can run cmd.exe in rxvt or something if you don't like the default windows terminal. I would assume the same is true for this.

Re:That's the terminal...

[Trejkaz]

I ssh into localhost using PuTTY. That gives me the best results so far.

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.

Re:Maybe we can learn something from that

[yandros]

We've learned over the years that there is incredible value in human-readable, text-based transmission protocols. Take a look at this ACM paper, for example.

Primarily, this value appears when debugging, when exploring, and when trying to do something new. The primary downside of this approach is performance. This means that `parseable, readable text versus efficient, compact binary' is usually an engineering tradeoff.

In the majority of cases, the computer is more than fast enough to handle the parsing, since, well, that's what computers do. What programmers generally do is the other stuff -- debugging, exploring, and trying something new. This often means that readable, parseable, text-based protocols are to be preferred.

Certainly, there is value in the idea of a `standard serialization system', but it's very easy to want to include everything. For example, look at any of the recent work on XML.

Re:Come kick the tires OF WINDOWS XP

[MSFanBoi2]

Are you saying if you use linux, you are running one of the early 2.4 kernels?

Why is it OK for people to constantly upgrade their kernels (or hell look at MacOS X and having to pay to get upgrades), but it's not OK for Microsoft to do so?

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:Why?!?

[EvanED]

And you -- still typing after all these years, over a hundred now, since the invention of the keyboard

But probably on a QWERTY keyboard.

Which actually swings in favor of his argument to a point.

Re:Why?!?

[vidnet]

Wheel - Which presumably replaced sleds and similar for land transportation

Fire - Mostly replaced by electric ovens for the average person

Fonts on graphical displays - Which replaced printed output and character grid terminals

Mice - Which replaced light pens (and has since been replaced by optical mice)

Silicon - Which replaced germanium, in transistors which replaced vacuum tubes

Bits - Which replaced higher base digits in early computers

Electricity - Which replaced steam and hand power in [then mechanical] computers.

Computer instructions - Which are replaced or at least modified for every new generation of processor

So none of the things you mentioned are the first, and none will be the last.

Re:Why?!?

[A nonymous Coward]

Fire - Mostly replaced by electric ovens for the average person

Tell that to your average person using your average internal combustion engine or power plant, or to your average third worlder who cooks with fire.

Bits - Which replaced higher base digits in early computers

Decimal computers represented those digits with bits. I worked on several of them.

So none of the things you mentioned are the first, and none will be the last.

NOTHING is the first and will be the last. Your turn ...

Re:Why?!?

[somersault]

fire seems like it could have been first, unless people used to cook their food just by leaving it on a warm rock somewhere.

He does have a good point, that people always assume that newer = better though, when it does not. Some newer ideas turn out better, some worse. It's a form of natural selection, though with some things such as QWERTY keyboards, people just accept the first semi-decent device they get, and then are too entrenched in their habits to be able to change. Even though I've heard the pros of Dvorak I dont really want to change - I can type ~70wpm after using a QWERTY keyboard for 19 years, and retraining to use Dvorak would be worse than getting used to 'inverted Y axis' on Quake/whatever (which I did for a year or two, then switched back after my dad kept complaining about me fiddling with the settings, in the days when games didnt tend to have different profiles), which isn't much fun.

Re:Why?!?

[vidnet]

NOTHING is the first and will be the last. Your turn ...

My turn to what? Sounds like you agree.

Tripple-<i>: Why haven't you graduated to something modern?

He has. Repetedly.

Re:Why?!?

[shaitand]

What is your point? That things progress? Certainly. The parents point is that they progress when something better comes along, NOT because the best solution has been the best solution for a long time (long relative to human time perception, a completely arbitrary standard).

Re:.Net rocks

[Procyon101]

Actually, if you know C++ or java, then C# is a peice of cake. I would hate to move to C# from a background in only C.

O/T: Polish?

[ZxCv]

I program in C# daily. It is Java, redone decently, with a couple extra features but without some of the polish that Java has.

Just out of curiosity, specifically what polish does Java have over C# in your eyes? One of the things I've always liked about C# over Java is that to me it seems more polished, so I'm just curious what makes you think the opposite.

Re:O/T: Polish?

[Procyon101]

The libraries don't seem as polished in alot of ways as Java's do. Take collections, for instance. They do not use standard terminology to identify the collections for one, but rather show some of their VB heritage. When they added generics, these were not a simple drop-in, like Java was, but rather a non trivial shift to using a different set of collections.

Often times in .NET the lower level library API's are not documented as well as Java's are, and sometimes not at all. All in all, it just seems a bit "clunkier" of a library. Not that it isn't a very good library, but Sun has just added that extra spit and polish. As with most MS dev environments .NET, while being by far the best library suite ever to come out of MS, has more of a maverick "git-r-done" coding style than the sleek and stylish. That's not always a bad thing, as someties doing things the pretty way is not the easiest or best.

If I had to choose between the 2 languages for a project, I would most likely choose Java, but mainly because of 3rd party library support (eclipse and hibernate having no equal). From a language standpoint, they are both on pretty equal footing, with both languages having slight advantages in certain areas, but functionally they are so similiar in both feature set and style that they are more of a separate dialect than a seperate language.

Re:.Net rocks

[resonantblue]

I stand corrected. C++/Java is actually more appropriate to compare to C# ... that's correct. That's what I intended to say :-)

Re:Command-completion as well ...

[EvanED]

At least in XP Pro, tab completion is on by default. In fact, I don't see a way (other than reghacking) in my brief search to turn it off. I believe it was in 2K too, but I'm not sure about that one.

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

[EvanED]

Roaming profiles
nice idea. Home directories that travel. Watch 20 users save everything to their desktop for about a month- train wreck.

PSU uses roaming directories. They (almost always*) work fine. They need a third-party tool to enforce a 20MB quota on desktop size, and have actually I think completely changed the setup so that the desktop gets loaded from a network path so that they don't even need that.

If I were making a network with Windows machines in which people moving between computers was common I'd say there's no other way to approach things than roaming profiles. It's WAY too useful.

* There's been a couple hiccups in my 4 years here, but they consisted of it just taking an incredibly long time to log on.

Face it. Microsoft has been saying things will get fixed with the next version since windows 95. They've not delivered on that yet as far as I can tell. More features get added, but nothing gets fixed, and the reason is because it makes for good marketing.

I'll grant you that there's a lot of empty promises and vapourware. (WinFS anyone?)

However, to say that the quality of Windows 95 is anywhere near the quality of 2K or XP is completely and utterly ridiculous.

cscript

[rp]

Microsoft have included object-based scripting for a long time (the Wi ndows Scripting Host).

    http://www.microsoft.com/technet/scriptcenter/guid e/sas_wsh_qlcc.mspx?mfr=true

But it's pre-.NET (you can do COM with it for instance).
I don't know if they also provide a .NET-based scripting shell.

Re:Command-completion as well ...

[trezor]

Try TweakUI on Microsoft's PowerToys for Windows XP page.

Mighty useful tool, if I may say so.

Cloned within a month?

[tjwhaynes]

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.

Cloned within a month? Sorry to rain on your parade but if you wanted an object shell, you could have been using one for more than a year already. Take a look at Object Shell which has been under development since October 2004. It's written in Python and uses Python objects.

Cheers,
Toby Haynes

Exchange 12

[xbrownx]

Why is it going to debut with Exchange 12?

Are they expected email admins to go nuts creating new scripts now? Seems like it's not exactly their target audience...

Re:Exchange 12

[multi io]

Why is it going to debut with Exchange 12?

Improved mail virus scriptability? :D

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

Re:Amazing Microsoft shell skillz!

[CrankyOldBastard]

As are ps, grep, sed and awk.

On my system ls is as well. So your point is?

a proper response

[namekuseijin]

Although probably someone already replied something along these lines, i can't resist:

"When MS-DOS was first written, there was no such thing as directories...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 /."

This seems the typical M$ fanboy who thinks M$ invented everything in the IT business, from directories to operating systems, to GUIs to spreadsheets.

Well, yes, both directories and the convention to use "-" switches to pass command-line options to programs already existed in Unix. And Bill Gates the man was very aware of them and even used vi back them. They purposefully introduced annoying new conventions, like "\", "/" for switches and "dir" rather than "ls", while some other things remained the same such as "cp", "more" etc...

However, since DOS was actually created by another company, it may not be the fault of M$. Just maybe...

Interesting to see the mindset in action

[dilvish_the_damned]

Its interesting to see the windows mindset put into action in a shell like fasion.

FTA:
$ ls -l | awk '{ tot += $5; print tot; }' | tail -1

This reduces the complexity, but requires specific knowledge of a new language, the language that is associated with the awk command.

The MSH loop is similar; each file in the directory is needed, but it is far simpler as the information about the file is already retrieved:

MSH:

MSH> get-childitem | measure-object -Property length


Yes, but using awk like this will work for any similar problem only requireing you to think about the format of the output, whereas this other way requires specific knoweledge of possible properties. I can see some advantages, but don't assume its better because you dont need to learn a new language, cause you basically do.

Convergence

[kompiluj]

Ok. I will be rated troll like last time, when I said that Debian is a very good platform for customized distributions (it was before widespread successes of ubuntu and mepis).
I see that both families of systems - the Unix heritage (Linux, Solaris, BSD less so - they are more true to the original Unix, maybe with exception of dragonflyBSD and Darwin) and the VMS heritage (I mean Windows here) are converging. The aim seems to be a kind of thread based, light-kernel operating system, that can be easily parallelized/or distributed, with object oriented interface at both Kernel and User levels. The Unix was taken in this direction by Plan9, Mach and NeXT.
Think I am a loony? look here: Plan9 shell introduction.
Unix shell (text) ---> Plan9 shell (arrays of strings) --> Microsoft shell (objects).
I'm also certain that there will come time when Windows will become Open Source, like Solaris. Not that I like Windows or whatever but Open Source is more functional, so the convergence process will also take Windows in that direction.

Another Microsoft "innovation"

[metamatic]

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.

Wow. It took them a long time to copy AppleScript.

For those interested in UNIX like shell on windows

[undeadshell]

I am working on a unix like shell for Windows that includes a more modern UI. If you are so interested check out www.undeadshell.com. I am still developing it so its a little rough around the edges.

Re:.Net rocks

[resonantblue]

Technically, yes, though "Practical Extraction and Report Language" has been widely suggested as a backronym.

YES!!!

[solomonrex]

Thank God. It's why I use it. Sorry, but cygwin's a little idiosyncratic, so until Redmond releases a real Bash on XP, this is it.

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

[petermgreen]

PSU uses roaming directories. They (almost always*) work fine. They need a third-party tool to enforce a 20MB quota on desktop size, and have actually I think completely changed the setup so that the desktop gets loaded from a network path so that they don't even need that.

If I were making a network with Windows machines in which people moving between computers was common I'd say there's no other way to approach things than roaming profiles. It's WAY too useful.

Roaming profiles are based on the idea of copying the profile arround

this means people can work offline but as the GP has stated it gets totally impractical rather quickly.

the soloution at least for desktops is to just load stuff directly off network shares, giving up the ability to work offline but saving a LOT of network load. This is certainly achiveable but it means a LOT of work manually reconfiguring applications and the OS to move stuff out of the profile and onto network drives.

Re:Command-completion as well ...

[6th time lucky]

i believe it is on for filenames but not directories... or vice-versa.
And yes TweakUI will let you set it to both easily.

*NIX Response?

[KevinGlenRoyGreer]

I wonder if the open-source community will rise to the challenge of providing something as good for *NIX, or if they will simply live in denial of MS's genuine advancement/advantage. I think that we now need to update all of our *NIX/Windows Advantage/Disadvantage tables and move the "scriptability" check to the other column.

It's not even clear that you could create something similar for *NIX given that MSH is build on .Net so actually has lots of Objects to script whereas an Object-based shell and *NIX would be lacking any Objects to script. Actually, UNIX is an OO system in a very limited fashion, be it one with only one interface: File.

I asked James Gosling whether the Solaris team at Sun was doing anything with Java to add MSH-like capabilities to Solaris. To make a long answer short, he basically said "no".

Many of the high-order functional programming aspects of MSH remind me of a UNIX shell from around 1990 called "Es". You can read about it here: Es: A shell with higher-order functions.

Wrong

[CarpetShark]

If you knew anything about the history of NT, you'd know it has changed many things and still IS changing many things to make it more unix-like, so obviously they do need to learn from unix.

Nope.

[CarpetShark]

They implemented it for the sake of being able to claim compliance in case big clients had specified that, but it wasn't a real effort to comply in anything but name, and so it has been abandoned now:

http://support.microsoft.com/default.aspx?scid=kb; en-us;308259

NDOS / 4DOS / 4NT has been around for 15-20 years

[ClioCJS]

And I see no reason to switch to something new.

http://www.jpsoft.com

I've had aliases, tab-completion, and much more ... since the 1980s I believe. Objects are nice, but I never use cmd.exe anyway!

VMSNT connection

[ChipMonk]

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

My understanding is that M$ hired some VMS developers to be part of their Windows NT kernel team, which is why NT 3.51 was so stable (for a M$ OS). It started going to pot with NT4, as M$ moved away from the heavy VMS influence.

Not everything.

[warrax_666]

Network devices can AFAIK not be reached through /dev. (On Linux that is... I think it is true of the BSDs as well.)

Re:Vista: Includes Free RootKit!

[MECC]

Microsoft must have many people covering slashdot who have somehow gotton moderator points, for this the parent's comment to get modded 'troll' and 'offtopic'. I just ran into an obvious microsoft shill over on bugtraq. I suppose if I had as much cash as they did, I'd do the same thing. I wonder what the job title is?

I guess the parent must have struck a nerve...