This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Korn Shell

In message <>, you write:
> Yes but I could never get it to work with Gnuwin32. Cat,make,gcc nothing
> would work....
> Christoph Kukulies wrote:
> > 
> > On Fri, May 30, 1997 at 07:12:00PM -0500, Chris Jeffares wrote:
> > >
> > > Is there a Korn shell for the b18 ??
> > >
> > > If not is there a way to run a Korn Shell on an NT platform ??
> > 
> > UWIN ( (written by David Korn - no sources, btw)
> > would give you ksh.

This is not surprising (that the UWIN Korn shell wouldn't work with the
Gnuwin32 programs).  It's important to understand that both Gnuwin32
and UWIN are fairly complete operating-system emulations -- they are
not just a collection of Win32 programs that can interoperate seamlessly
with any other Win32 program.  They use different and, I'm sure,
incompatible methods to map UNIX semantics onto Windows semantics.
For example, UWIN assumes that any UNIX pathname of the form /c/... is
a reference to c:/... , whereas in Gnuwin32, you would have to do a
mount command to explicitly declare this equivalence.

Both of these toolkits suffer in interoperability from having the goal
of complete UNIX source-level compatibility.  I prefer the approach of
the MKS UNIX Toolkit, which adapts gracefully to the fact that it is
running under Windows.  The Korn shell in the MKS Toolkit fully understands
that "c:/..." is a reference to a drive letter, and will correctly do file
name completion and globbing on such strings (unlike bash).

It looks as if there are two different motivations for the existing UNIX
emulations on the Windows platforms:

	- The MKS Toolkit seems to be oriented mainly towards enhancing the
	  Windows command environment with the much greater power of the
	  UNIX utilities (find/grep/ksh, etc), rather than pretending that
	  Windows does not exist.

	- UWIN and Cygnus GnuWin32 seem to be more concerned with being able
	  to compile and execute UNIX source code under Windows without
	  changing it.  As such, they have much stricter need to emulate
	  the UNIX API faithfully, and need to avoid complete integration
	  with Windows.

I prefer the approach of the MKS Toolkit, since I'm only interested in
enhancing the command-level environment of Windows.  I believe that
many tasks can be done more efficiently with textual commands than with
a GUI interface, given the power of UNIX commands.

Just my opinion, however.  I understand the desire to port UNIX applications
to Windows so that they might have a larger market.

Michael Condict
The Open Group Research Inst.	(617) 621-7349
11 Cambridge Center
Cambridge, MA 02142
For help on using this list (especially unsubscribing), send a message to
"" with one line of text: "help".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]