Shells and POSIX

[Previous] [Next]

No discussion of Windows and UNIX interoperability would be complete without a discussion of the differences between their shells. Interestingly, no one has ported an emulation of the Windows NT/2000 cmd.exe shell to UNIX yet. But there have been a variety of emulations and ports of UNIX shells to Windows 2000, which is good because the average UNIX user wouldn't be willing to give up the full-featured Korn or POSIX shell to work within the limitations of the Windows command shell.

The Korn Shell

As you already know, SFU provides an excellent implementation of the UNIX Korn shell in Windows 2000. It's based on the MKS Korn shell implementation with the quirks that are native to that implementation.

The MKS Korn shell, either in SFU or directly from MKS, makes the maximum accommodation to the Windows 2000 world. It isn't case sensitive and will completely ignore case when matching filenames, although it will, like NTFS, preserve case. It also doesn't convert the Windows 2000 drive letter syntax into a more UNIX-like single root file system. This makes it feel quite comfortable for Windows 2000 users who sometimes also spend time in the UNIX environment, but somewhat less so for UNIX users who have to occasionally spend time at the Windows 2000 command prompt.

Scripts written for UNIX can be ported to an MKS Korn shell fairly easily. Functions are supported, and even double bracket compares ([[]]) work as expected. The biggest problem is handling drive letters and the resulting confusion of syntax. PATH entries are separated by semicolons rather than colons to accommodate the requirement to use colons after the drive letter; consequently, scripts that expect to parse the PATH statement using the colon as a field separator must be rewritten. And scripts that must work on both UNIX and Windows 2000 systems will have to be written with this consideration in mind—not hard, just not something the average UNIX user expects to have to deal with.

Another problem that scripts will have to address is the lack of a common root file system. This is best masked by using fully qualified filenames and paths in variables and then referencing paths relative to the variables rather than the explicit path. This isn't a big problem, and it will tend to support good programming practices in any case.

POSIX Shells and Subsystems

While the SFU (and MKS) Korn shell is simply another shell running on top of the native Windows 2000 kernel, some full POSIX subsystems also support UNIX at the kernel level. The best of these is undoubtedly the Interix POSIX implementation from Softway Systems, a fully POSIX-compliant subsystem that integrates directly into the Windows 2000 kernel.

The Interix POSIX shell takes the opposite approach from that taken by the MKS/SFU Korn shell—it makes virtually no concessions to the Windows 2000 world and instead implements a fully case-sensitive, rooted file system in Windows 2000. Consequently, scripts written for UNIX run exactly as you would expect them to run without additional changes, or at least that's the theory. However, the absolute case sensitivity causes no end of problems, and the lack of concession to Windows 2000 syntax means you need to remember that native Windows 2000 programs have names like notepad.exe, not notepad.

You can find ways around the problems, including using a set of utilities whose sole function is to convert Windows 2000 paths and case to POSIX and back. However, the issues with using UNIX scripts in both environments parallel those with the MKS/SFU implementation: you'll need to remember the differences and write your scripts to handle them.