Microsoft Next Generation Shell

An anonymous reader writes "I found this while searching for Perl Jobs in India: "The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the .NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."

Comments

Cygwin

[TheShadow]

I liked this the first time... when it was called Cygwin.

Re:Cygwin

[Anonymous Coward]

I liked this the first time... when it was called Cygwin.

For those whou don't know, Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: (1) A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. (2) A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. The Cygwin DLL works with all non-beta, non "release candidate", ix86 versions of Windows since Windows 95, with the exception of Windows CE.

Other thing which I'd suggest for anyone who is unfortunate enough to work under Microsoft Windows is Perl Power Tools: The Unix Reconstruction Project. The goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so. See the command list.

(I post as AC, because I'm not a Karma whore or anything like that.)

Re:Cygwin

[kraf]

Or MinGW if you don't want to rely on cygwin.dll.

Re:Cygwin

[joeykiller]

How this can be considered Insightful beats me. Cygwin is an attempt to create a Unix emulation layer on Windows, while this apparently describes a fully flegded .Net integrated shell enviroment for Windows.

If this is true, this will (in my opinion) give Windows a tremendously powerful and coherent (i.e. a single understandable object model and class library) scripting and shell environment.

Say what you will about Cygwin - I like Cygwin a lot and use it daily - but it cannot be said to be coherent and consisting of well integrated parts.

Re:Cygwin

[Doc Hopper]

I feel the need to respond to this, though the parent poster borders on flamebait.

You've provided a straw man argument in "Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format", and then attempt to categorize Eric S. Raymond and other UNIX or Cygwin users in this light. Cygwin is a tool, part of your arsenal of options in systems administration, and nothing more. The ability to obtain a UNIX-style directory listing is irrelevant compared to the ability to use the same script to accomplish the same thing regardless of software platform.

• "Using Cygwin under Windows is about as intelligent as using Microsoft command shell batch files on UNIX."

"Crock of Crap" is the first thing that comes to mind. Bash/tcsh/ksh/psh/etc. are so many light-years ahead of the MS-DOS command line scripting language when it comes to pure functionality and understandability that there it is difficult to know where to begin creating a valid comparison. Using a Bash shell under Cygwin to accomplish systems administration or automation duties on W32 is a sound, rational decision for reducing your time investment when supporting legacy platforms like Microsoft Windows 32-bit stuff. Using Cygwin to be able to provide environmental portability across platforms can be an intelligent, measured decision that can make sense both on a personal level as well as corporate decision-making.

• Many of the [legacy W32] command shell commands are designed to handle the way you do things in the Microsoft world ... using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.

You've made at least one incorrect assumption in this paragraph, and that is that using Cygwin makes DOS scripting unavailable. That is simply not true. Every facility of the MS-DOS command shell is available via a Bash shell in Cygwin. You can call external programs, or even use an MS-DOS batch program to launch a Bash shell. Cygwin gives you more power and flexibility to deal with all the things you wrote of, not less, and in a fully POSIX-compliant environment to boot. Using Cygwin is a giant step forward, that is, unless you are mind-locked into the legacy Microsoft Windows paradigm.

• the command shell being too incomplete... I also think this has been a good thing. [I can see] when shell scripting is at its end and jumps to coding a c binary to do something... Using shell scripting for real programming is like using Perl to write a database. It's just silly

You're entitled to your opinion. I'm a professional systems administrator, not a professional programmer, yet I've used Perl, Python, Bash, Cshell, Visual Basic, Excel scripting, MS-DOS command scripting, TCL, and other languages to automate certain tasks, make my job easier, or provide additional functionality where it was needed. Each tool has its place. I would not use Python to attempt to create a performance-critical OpenGL game, no more than I would use C to write a small daily cron job that mounts a filesystem, copies files, and unmounts the file system. Each tool has its strength. Cygwin and the programs available within that environment allow you to do more and go further with command scripting than MS-DOS command can possibly do. The "jumping off point" to an alternative language is very, very low on W32 MS-DOS scripting. Conversely, the "jumping off" point using a real, powerful command shell is quite high, and allows you to accomplish a great deal without having an enormous knowledge base of various programming languages.
The line between "scripting languages" and "programming languages" doesn't exist except at some arbitrary line which differs from programmer to programmer. Whatever language lets you get the job done in the shortest amount of time with the greatest degree of maintainability is probably what you want to pick. I can take my pick of Perl, Python, Bash/csh/ksh/whatever, Java, C, or anything in between to create what I need to get the project complete. Cygwin lets me have that additional flexibility, with the side benefit that I can use the superior command-line tools (grep/awk/sed/uniq, for instance) of a UNIX environment from Windows.

• They just learned a few words, then decided that the rest of the vocabulary wasn't needed.

The world always has a need for the simple, elegant, and practical. I would submit that your analogy is flawed. Allow me to share an analogy of my own. I recently had a choice of transportation to and from work, between daily riding the bus (an hour and fifteen-minute affair each way), or driving my car (45 minutes each way). Now, for many people, the choice is very obvious: Use the option that takes the least amount of time, driving the car. Given only the time data, many would come to the same conclusion, that driving the car takes 1.5 hours per day, while riding the bus takes 2.5 hours per day. This overly simplistic view of the question doesn't nearly cover all the facts, however. Here are some other factors that influence my decision:

• My car consumes a gallon of gas every 30 miles. Work is 40 miles away, so I will fill my 10-gallon tank roughly every 3-4 driving days, which will cost me somewhere a bit less than $20 each time
• My work provides me with a parking space ($40 value) or a bus pass ($40) every month.
• I have to pay for maintenance on my car.
• Time spent in the car is time that I cannot do something else: I must be exclusively driving

On balance, I decided to take the bus. The extra time consumed by the bus ride is time that I can sleep, work on my laptop, or read a book, whereas if I were driving that hour and a half would simply be lost to me.

How does this relate to the question? Well, I think your perspective on why people use Cygwin and other UNIX-like tools on non-UNIX operating systems is a bit skewed. The native tools may be elegant, powerful, and complete (which would be quite a debatable point on legacy W32 platforms IMHO), but the question lies in the balance. Would using native tools allow you to take that same programming effort and use the same script on another operating system? Would using native tools give those who follow you a proper perspective on how to maintain your programs once you've moved on? Would re-implementing something in a native tool, when one could otherwise just install Cygwin and run the same code that is running elsewhere in the enterprise successfully, be the best use of time and the company's dollars?
Regardless, when using Cygwin you are using the native tools available to you, but just substituting a powerful command shell and scripting language for the severely retarded one that is provided by default on W32. "When in Rome" (or some foreign operating system), they say, do as the Romans do. However, if doing so would compromise system integrity, maintainability, stability, or compatability, then I do whatever I need to to make the system work well, even if it requires using a tool that doesn't quite seem "native".

I do not use Cygwin much myself. I boot to Microsoft Windows to run legacy or gaming applications on my home system, and exclusively use GNU/Linux at work and home otherwise. I do a lot of work with legacy W32 systems at work and am a big fan of "use the right tool for the job", which, to date, has not included installing Cygwin on those machines. However, it has included installing Perl, Python, or TCL as the situation requires; if Cygwin were needed to make something work, I'd use it as just another tool in my box.

Get with the program! When running any OS, use the best tool for the job!

(As a final note, I think it's very interesting that Microsoft has finally acknowledge that their shell is horribly crippled and are working to fix that. I'm not anti-Microsoft, I am pro-GNU/Linux, and am very excited to see them finally addressing the massive wart of a lack of decent systems automation on W32 platforms.)

And they can call it. . .

[kfg]

bashWinXP

KFG

wonder what this means

[neildogg]

"Candidates should have Windows NT or Windows 2000 system programming experience, development experience with object-oriented languages and design methodologies as well as with scripting and shell languages like PERL, Python and Bash. Candidates should have at least 2-5 years experience (based on level interviewing for) in high technology, preferably delivering products for both Windows and non-Windows operating systems."

I guess Microsoft has viewed users of other platforms as important before (recruiting of Palm developers) but this seems like a direct call to Unix (mostly Linux) developers to make Windows shell exactly like other existing technology. Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Re:wonder what this means

[IamTheRealMike]

Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Actually, the next version of IIS has dropped the binary metabase and has replaced it with XML config files, so IIS can be administered by hand, just like Apache (but with a pretty GUI if you want one). Maybe as part of this next-gen shell they'll introduce a good command line text editor.

This sounds to me very much like Microsoft is having a good hard look at what Linux/open source does well, and copying it. Fair game - we've copied them plenty, and are continuing to do so. We could well find that Windows moves on a lot thanks to the competition offered by Linux: will we be able to keep up, and keep pushing things forward to? I think so. I hope so. But the era of kicking Windows for being unstable is already over, insecure looks on its way out (I read coders can get fired now for writing insecure code at redmond), and soon traditional UNIX strongholds like good remote administration may no longer be unique either.

We have our own stupid problems to fix too of course. Lack of a decent object model? Lack of binary portability? That one is killing us at the moment, and there is no good solution (as I'm finding out as part of my project). We really really don't want to have to setup build farms (a binary for every distro version), that'd suck. But it seems the very nature of Linux itself dictates it. Now Windows is moving to .NET they are tidying up a lot of these problems, while we're still playing catchup.

It's certainly going to get interesting soon. Microsoft have sort of woken up.

So, we're back to the 60's.

[pmorrison]

All my friends who learned to program computers (ok, Windows) in the 90's think it strange that I keep one or more command prompts open to get work done. Besides having 'grown up' with prompts, my argument is that the core of programming is algebra+logic, and text makes a pretty good notation for both of those things... it's a much better graphical notation than anything developed in the last 40 years. So it's heartening to see even MS come back around to the way things were.

Re:So, we're back to the 60's.

[Gordonjcp]

Well, I do a lot of graphics editing, including resizing and thumbnailing images from digital cameras. It's far easier for me to knock up a script to do this than to struggle with GUI programs to get the job done. Since they're going to go on a Unix webserver anyway, I can just resize then scp them across. If I'm doing a heavily graphics-orientated project, a GUI works well. If I know exactly what I want the machine to do, command line can be better - it's usually easier to ask for something by name than to point at it, in the hopes you'll be understood.
Consider - I want to resize a directory of images, and put them in a thumbnail directory. Which is easier?
Command line:

mkdir thumbnail
for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;

or GUI:

Click File/Open
Go to the right directory
Open the file
Click on Edit/Image Size
Set it to 128x96, or 96x128 depending on if it's portrait or landscape
Click Save As...
Go to the right directory
Click OK
Go back to the start, until all 300 or so images are done....

Re:So, we're back to the 60's.

[droid_rage]

You could have easily done it with ADSI in VBScript which is already natively supposrted. What were you trying to do, just write a script to add users? How about:

Function CreateUser(sOuDomainPath,sUserName)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sUserName)
oUser.Put "sAMAccountName", sUserName
oUser.SetInfo
oUser.AccountDisabled = False
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser = True Else
CreateUser = False
End Function
Function
CreateUser2(sOuDomainPath,sFirstName,sLastName,sDe scription,sEmail,sPassword)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sFirstName & " " & sLastName)
oUser.Put "sAMAccountName", Left(sFirstName,1)& sLastName
oUser.SetInfo
oUser.FullName = sFirstName & " " & sLastName
oUser.GivenName = sFirstName
oUser.Sn = sLastName
oUser.AccountDisabled = False
oUser.Description = sDescription
oUser.SetPassword sPassword
oUser.Mail = sEmail
'oUser.Profile = "\\server\share\username"
'oUser.Put("HomeDrive"),"X"
'oUser.HomeDirectory ="\\server\share\username"
'oUser.LoginScript = "myscript.vbs"
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser2 = True Else
CreateUser2 = False

End Function

That's actually some code that can be easily found in a number of locations Microsoft, for example.

Im not a huge fan of MS (Read my journal for opinions on your run-of-the-mill Windows admin), but I wish people would stop bashing Windows for a lack of understanding on their part. Most of this stuff is in the Windows 2k Server resource kit, too. I guess your company didn't shell out the $100, or you didn't read it...

Development in India

[slashuzer]

It would be interesting to know just how much of Microsoft's "future devlopment" are being made in India. My guess is that the OS, Office etc continue to be further developed by the team(s) in Redmond, but most new products/services are being developed in India.

Good step

[Captain_Frisk]

This is a good step, but what good does it do to have a top notch shell, when the vast majority of windows programs are gui based?

Are they going to release command line versions of most of their administrative tools?

Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it.

Re:Good step

[oren]

You are missing the point about this shell making heavy use of the .NET framework. Presumably, any .NET object would be accessible to the command line... Given that they intend for their whole OS to be based on .NET, this means the command line may offer access to more functionality than /bin/sh offers on a UNIX platform.
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell, rather than a simple shell replacement.
If this achieves its potential, Linux/UNIX may end up playing catch-up on the CLI front as well as on the GUI front. Good move for Microsoft, and one that would be hard to counter in the open/free software world because we have no universal object-based virtual machine/interface for use as a basis.
Or rather, I should say we have too many - Java, CORBA, the Mozila components, and even .NET (Mono). Microsoft could, if it plays nice, actually set a new portable standard for shells (based on .NET on Windows and Mono on UNIX). Of course, knowing Microsoft, they'll blow it by succumbing to the temptation of poisoning it with all sort of Windos-isms. This will be interesting to watch...

Re:Good step

[sheldon]

"This is a good step, but what good does it do to have a top notch shell, when the vast majority of windows programs are gui based? "

Think outside the box...

In Windows we're not limited by piping text from one command to another. We have COM automation today which allows one to instantiate Microsoft Word as an object and issue commands to it. This new scripting/shell will apparently allow for similar automation using native .NET framework objects.

"Are they going to release command line versions of most of their administrative tools? "

command line version of administrative tools have been available since NT 3.x. For those that don't you can use WSH to automate the task.

"Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it."

Huh? Can you open up the word processor in Star Office and build a document based upon data you pulled from an Oracle query, complete with various layout features from a Unix shell script?

We've been able to do that from the Windows command line for several years now. I don't think you fully understand the scripting capabilities Windows offers.

A good thing, really.

[bdowne01]

Actually, I'm really intrigued about the possiblity of having a "strong" shell on Windows. It's one of the main reasons I can't find myself using Windows for much.

Usually, if I had to...I just installed Cygwin and used it from there. However, the interaction between the actual Windows environment and Cygwin was a little cumbersome--but usable. I've written some crazy shell scripts using Cygwin, but trying to run a Windows command using variables from the script can be tricky, for example.

However this opens up some other nice possibilities for a Windows environment. If the shell they create is complete enough, you may not even need stupid "remote control" apps, instead you could just SSH into the box and take care of things.

On the other hand, I guess it just makes Windows easier to crack too ;)

they'll screw this one up as well

[g4dget]

I am sure Microsoft will do everything they promise, and as a result, their new shell will be absolutely awful. Microsoft's response to everything is "we'll implement something with more features, more technology". What they don't get is that simplicity and restraint is valuable in itself. You can see this throughout their systems. Their file systems are becoming databases. Their programming environment is fully object based and component based. Their file system protection allows you to specify arbitrary ACLs on arbitrary files. And on and on. In different words, just about every single one of Microsoft's products suffers from the "second system effect".

Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.

WSH

[lseltzer]

Most of these capabilities are already in Windows Script Host, which has been standard in Windows for years. What's new, I suppose, is that this version is based on the .NET Framework.

This validates the UNIX way of doing things ...

[RNG]

For years now MSFT has said that their platform is more user friendly by providing nice GUIs for all admin modules.

For them to turn around and now build this super-shell basically amounts to admitting that a GUI based aproach does have some serious shortcomings and that the UNIX way of allowing everything to be scripted provides serious benefits which are hard to come by if everything is accessed through a GUI. If nothing else, this validates the UNIX way of doing things and should make it easier to argue this point when competing for (a) large (number of) server installs/farms.

Virus delight

[corvi42]

Wow, a hugely complex scripting environment with hooks into every aspect of the OS.
Virus writers - here is your big chance to spread like wildfire through windows machines!
.... Again!

MS was at USENIX/SAGE asking what makes a good CLI

[furry_wookie]

FYI.. .I was at the USENIX/SAGE L.I.S.A Confrence 2002 in Philly a few weeks ago, and some guys from Microsoft had a late night get together to talk to us unix people. I couldn't not go, after all it was Microsoft at a 100% NIX-only event, so I figured some fun would be had at their expense.. It was called: UNIX + Windows Admin Management with Scripting & Command Line: What are your requirements?, and was on thursday night. The point of the meeting is that, they wanted to know from UNIX admins what makes a good Command Line environment and what it would take to make Windows have as powerfull a CLI as Unix. They pretty much told us that there is a LARGE high-level project at Microsoft to make Windows servers to be as easy to manage and configure as Unix servers from a serial port with no gui required. What is their REAL goal: From what I could tell its simple... they want to eliminate the competitive advantage that UNIX has with the CLI. That this away from NIX as a "advantage", then thats one less think people can point to as something that Windows lacks. They want to be able to honsetly say... "Unix isnt any easier/more-powerful on the CLI than Windows." After all, that is one of the SINGLE LARGEST differences there are today between their product and NIX. Take that argument away, and you have a huge marketing/argument weapon against us NIX people.

Re:What the...

[CoolVibe]

This and all of the similar idiotic comments just goes to show how little the /. crowd knows. Reading even the summary of the article shows how untrue this is. bash has command discovery via reflection API's? Really? It can discover commands by any other mechanism than searching the path? I think not.

tcsh can. Guess the problem is still solved. tcsh can expand command from other 'completors' other than just the $PATH. Like, type mount somehost: and it will try to expand from the output from 'showmount -e' for example. Granted, they aren't reflection API's but that's just another buzzword to me :)

The job is indeed in India

[Doug Merritt]

the job listing was most likely a job in redmond washington, but posted in an indian job listing to specifically recruit indian guys.

It's not necessary to carefully avoid reading the very short page that this story is about. It's not necessary to make a (completely wrong) wild speculation that is trivial to double-check just by glancing at the final line of the job posting. It's not necessary to embarass yourself in public. The final sentence of the job posting says:

This position is in Hyderabad, India.

Of course, this is the first time anyone on Slashdot ever posted something incorrect without reading the story in question, and doubtless no one will ever do something that silly ever again.

Way to Go, Microsoft

[SecretAsianMan]

This is the moment of truth for all you people out there who have made arguments like the following:

• Having both Gnome and KDE is good because the competition will cause both to get better
• Having a Linux/UNIX desktop environment is good because the competition (with Windows) will cause both to get better

I've seen these kinds of arguments spouted repeatedly by purveyors of the Slashdot party line, and I've even made a few myself. What we have here is a confirmation of the underlying idea: that competition improves products.

Plan and simple, Microsoft is competing. They've acknowledged a strength in a competitor's product and are (finally) going to tackle it head-on instead of with shady business, cash, and lawyers. They're going to try to build a better product. This is what we've wanted all along, isn't it?

I wish Microsoft's programmers the best of luck in creating these new features. They will most likely be a great improvement to the Windows platform. Likewise, I wish the Linux/UNIX communities the best of luck in creating new features to greatly improve Linux/UNIX. I believe that competition between the two groups will significantly advance the start of the art in software. Microsoft is ready to play serious but fair ball, and it's up to the rest of us to build a winning team and play the game. Humanity stands only to gain.