RANT_MODE=1: Current generation shells -- Will Microsoft Ever Fill The Needs of the Enterprise?

FeriCyde Chat

A good friend of mine recently pointed me to this blog entry by Joe Brockmeier on a subject that's dear to my heart: shell programming. In case you haven't heard, Microsoft is touting a new shell that's going to do some neat things for LongHorn when it ships in the very near future (2007). I've been somewhat fascinated by the whole "MSH" (Microsoft SHell) concept since hearing about it a year or so ago, so it was interesting to read Joe's take.

The blog entry, however, has a rather misleading headline. It's titled "Next-generation shells - is Linux falling behind?", which prompted my title. You see, Microsoft hopes to be somewhere in 2 to 3 years that is at least on par with where Linux is today, and I don't believe for a second that for one, they'll be there (where Linux is today) or even that they understand the problem they're trying to solve with this new toy.

But Joe's missing the point here as well. He does make some bold statements about Microsoft innovating some object abilities in pipelines, and how that's new -- and it may be for all that matter.

The general tone of the piece, however, is quite misleading. Before I get started, let me explain that I speak from a base as an enterprise-class Unix and Linux engineer. I've got quite a few years behind me doing that kind of work and in general, I'm an automation freak of nature.

First and foremost, enterprise-class data and systems management demands solutions that are available today -- not literally 2 to 3 years from now. It demands programming that can withstand the test of time. These solutions should be cross-platform, extremely standard and stable. Stability is something typically measured in years of service in non-interactive situations. It's a reputation that comes about, in other words, by dependence -- no amount of marketing hype is going to answer the bill here.

Yes, as alluded to in the article, some people would point to the fact that backward compatibility hasn't changed in bash, and that new features (in their humble opinion) haven't appeared at that fast of a rate. For what it's worth, I disagree. Every time I load a new Linux system I find some new feature in the shell environment that's really awesome. These new innovations don't break the sound barrier, but make things incrementally better without breaking past compatibility (a common theme of this article). Color, for example, is a really common thing found in the utilities under Linux -- and that's just one dimension. I could blather on about all of the neat command line switches that add capabilities to typical Linux utilities all day -- but that would be missing the point.

Here's where logic and reason really go south, in other words. Bash (and other POSIX shell's, such as the Korn shell) have been proven and capable solutions that adhere to a standard for years. The POSIX standard is actually bolted on top of Korn shell's 1988 specification.

This means that it's theoretically possible to have shell code that's 15 years old today and still doing worthwhile work. In an enterprise-class setting, that's no small item.

That is everything.

Let's not also forget that enterprise-class operations require people with proven understanding and experience with these technologies. Who wants to be the one to beta-test all this new Microsoft garbage with enterprise-class data?

So, no offense Joe (or Dana), but I think I'll take the capabilities out of the box for managing complex systems in large quantities that Bash and Korn shell offer today. I'll also leverage Python, Perl, TCL, expect, gcc and a host of other built-in languages, each suited for some portion of the job to do the stuff that needs to be done across multiple operating systems -- even Windows.

Truth be known, it's possible to load Cygwin on a Windows box, with secure shell daemons and all, and treat it very much like another Unix box (using the "uname" function to determine what "flavor" of Unix you're messing with). This is way more valuable from a systems management perspective than some nifty new shell, in some nifty new operating system and written to some nifty new proprietary specification. What about the possibly of the MSH "standard" changing like a flag in the wind? What real standard is it based upon?

In case anyone is wondering -- yes, I've actually been involved in the deployment of Cygwin in an enterprise class setting, at a fortune 500 company no less.

Oh wait, there's more good Microsoft shell news! I get to wait until 2007 before it becomes stable and usable. I forgot that. And it's going to do what that I can't do today? Maybe do some exotic file manipulation with objects?

The examples (XML and a spreadsheet as output) given in the article are possible with a decent awk or Perl script today. The output of a system command that contains some arbitrary data is now and for the foreseeable future, text. True, ASCII is a rather clumsy data mechanism, but often data doesn't come to you in neatly defined object packets -- data comes in a multitude of formats and you have to figure some way to clean it up to get to the core aspects that are hidden in there somewhere.

Awk (a shell utility found on any Unix or Linux system deployed in the past 2 decades) does that nicely, and Perl can be used for the binary stuff. Systems information is typically not object data, from experience. It comes from any number of sources in various states of representation -- but almost anything can be reduced to a text stream of some kind, and that means we're back in shell territory. The shell provides almost 4 decades of refinement from multiple mindsets to deal with that text, and do useful things with it in the end.

I speak from extensive experience here -- CSV spread sheets (an Excel data file import/export format) are easily created right out of any plain old shell today. I've been told (but never found a practical usage for it) that there are modules to directly read and write spreadsheets as well with Perl.

The idea of needing some new Microsoft language to do this smacks of the usual proprietary madness that investing any time in their idea of management brings to the party. My verdict: It's not enterprise-class stuff, in other words, because it likely will never cross platforms easily, and for all of the other reasons outlined here.

It's likely going to help people that are stuck with massive Microsoft-only platforms to support, and that may be a good thing for them. In 3 years. Maybe by then they'll have some community based development going so they can leverage some automation that runs in this new environment.

It will likely be, still, a stark contrast to all of the automation and command-line stuff found in a typical Linux distribution right now. That automation has been going strong for how long? Decades, if you count all the Unix inertia. Given the fact that porting scripts and even executable code from these systems is extremely easy (even to Windows now that Cygwin is stable) makes investment in this thing a real long horn, er shot, I mean.

Don't get me wrong, it's a great thing that Microsoft is finally listening to the command-line jockeys out there. People have, for years, stupidly assumed that command-line operations were "archaic" and that shiny new GUI's were the next big thing. Microsoft touted this as an advantage for a long, long time, and it's good to see them finally admitting that it was a big mistake to put all the enterprise eggs in the GUI basket. In order to gain the enterprise traction that they want, they're going to have to listen to administrative needs, after all. They're doing this, in my humble opinion, because they're seeing Linux take huge sections of the enterprise that they wanted for themselves.

Please don't misinterpret the above statement either. GUI's are great for doing things that have been done before. They help new users of systems do extremely basic things and they make an awesome front-end to two dimensional tasks, like playing solitaire for instance. They're also good for fronting automated tasks that have been carefully refined. I love opening multiple Bash and Korn shell terminals with a GUI -- I wouldn't have it any other way.

They suck like eggs for things that are ad-hoc, creative and large scale. In other words, they're not very good at handling things that are enterprise territory. You're not going to easily do something that's never been done before to say, 2000 systems, with a graphic user interface and no shell or shell-like code of some kind. That's been the big lie and the marketing siren's singing that falsehood have been many over the years.

This new shell may be an object of beauty for some LongHorn users to admire. Will it ever have a POSIX standard like Korn shell or Bash? Will it ever run on a non-Microsoft based operating system? I think the answers to both of these questions are self evident. But we're talking about Microsoft, 3 years from now, and maybe by then they'll understand the power of playing nicely with everyone else.

Maybe.

In the mean time, a shell in the hand is worth any number of neat, shiny, vaporous objects in the bush.