Software and hardware deployments within most IT shops don't usually occur all at once. For instance, IT managers may have worked out a strategy for deploying Windows 2000 servers coexisting with Windows 98 (and even a few Windows 95) boxes. Over time, Linux servers begin to show up as well as Web servers and application servers. This raises some interesting problems for both developers and IT consultants as they work with both these systems. A subtle problem can be seen in the use of shell scripts.
As more IT shops move to mixed Windows and Linux environments, building and maintaining general utility scripts (still the mainstay of all maintenance and development programming for IT consultants) becomes a bigger headache. By using Red Hat Cygwin for Windows, you can create utility scripts that can power both your clients Linux and Windows systems.
What the shell does
The notion of a shell is very familiar to UNIX and Linux developers but isn't necessarily as obvious to consultants using Windows, where the tools for development rely much more on graphical integrated development environments (IDEs). A shell is a text interface with the kernel, providing a number of basic (and often not so basic) features from navigating directory structures to running applications to scheduling applications to run. In versions of Windows prior to Windows 2000, DOS was a shell application, while versions since then launch a Command Shell as a process under Win2K/XP.
Shell scripts can be thought of as the invisible glue that holds together most IT shops. Consultants often write shell scripts to automate batch processes. For instance, a Web order form application may produce a purchase order (as binary data or, increasingly, as XML) that could be stored as a file or a database entry. While it's possible for the same Web process that created the file in the first place to also process this purchase order, this adds to the complexity (and hence both running time and maintainability) of the application. Instead, it's usually preferable to queue these messages in a directory or database and then periodically run a batch file that processes these messages. These batch processes are almost invariably scripts. Other scripts may periodically check logs to make sure no abnormal activity is happening (or to record information into logs in the first place), converting files from one format to another, archiving, or other activities.
Shells under Linux
DOS (or the Windows NT Command Shell) came equipped with a small set of scripting utilities, but the language has long been of secondary concern to Microsoft; you're very limited in the kind of scripts you can write. On the other hand, Linux (and the various Unices) have developed a number of remarkably robust shells (from ash to zsh) that not only provide a number of rich UNIX commands but also include histories, the ability to work with regular expression patterns, and very sophisticated data piping capabilities.
Personal experience with Cygwin
I spend a lot of time jumping from Windows to Linux and back again, and there have been several times when I have typed in ls -l EBAY*.jpg to get a listing of all images starting with EBAY in a given directory, only to be informed by DOS that it doesn't understand what ls is or why I'd even want to use it. It was actually after an experience using PostgreSql in Windows that I inadvertently stumbled on a solution.
The PostgreSql database application was written for use initially in Linux. Rather than rewrite the application to work in Windows, the designers of PostgreSql turned to Linux software developer company Cygnus to create a Linux shell that could run within a Windows environment. When Red Hat purchased Cygnus, the Cygwin code was brought under the aegis of the Red Hat development team, which currently hosts it at Cygwin.com. Cygwin is open source and available free, and it is covered under various OS licenses, though there is also a proprietary license for companies that are looking at building their own proprietary Cygwin-based applications.
The realization of what this implies came to me when, after a longish session in Linux, I rebooted into Windows 2000 and, at a command prompt, accidentally typed the above expression. Rather than spitting out the usual “I don't understand” messages, it produced the unexpected output of a directory listing of all EBAY associated images. Mystified, I started working with some of the other Linux commands: cat output the contents of a text file (the command comes from concatenate, for its ability to combine multiple files into a single stream), mount provided a listing (in UNIX format, no less) of all of my Windows directories and storage devices, pwd gave my working directory, and chmod let me change the permissions on the various files. The weirdness factor got even stronger when I typed in bash and immediately found myself in the traditional UNIX bash shell.
Advantages and drawbacks
Cygwin emulates most of the core UNIX/Linux utility functions under Windows, making it possible to work with at least the shell-based functionality. While Xfree86 (the graphics server that acts as the foundation for graphical Linux desktops such as KDE or Gnome) can be emulated also, it is not as well supported. However, the network support applications are quite robust; you can use OpenSSH, for instance, to run scripts via the command line on any machine that has an SSH server. Also, Cygwin contains one of the fastest XSLT processors available on any platform.
At the same time, Cygwin augments rather than replaces the Windows DOS-era commands, so you can open Windows applications from the command line or even mix Windows and Linux commands (though this plays havoc with the portability between systems). One drawback of Cygwin is that it does require a significant amount of hard drive space (between 25 and 60 MB, depending on what you place on the system). And because it's an emulator rather than a true Linux, the script applications won't be blazingly fast (though even on my bare-bones laptop the processing time was barely noticeable). A final drawback is that Cygwin runs as a background process (primarily to handle scheduling capabilities through cron jobs), which means that it will be a slight drain on the performance of your development systems.
Add a little Cygwin to your Windows
Windows is a graphical interface, and while many of the tools can be invoked from the command line, the minimal support of the DOS command set makes that option typically unpalatable. By adding a touch of Linux to your client's Windows environment, you can consolidate scripts, minimize the hassles involved with jumping from one operating system to another, and significantly enhance what you can do with shell scripts. You'll make your clients happier and more productive in the process.