PageDump: Shells, terminals and MSYS

Preview: Page dump of Shells, terminals and MSYS

Date: Sat, 20 Oct 2007 16:20:15 +0000
Mime-Version: 1.0 (Produced by PhpWiki 1.3.14)
Message-Id:
<1314-1192897215+0000-MinGW%3AShells%2C%20terminals%20and%20MSYS@oldwiki.mingw.org>
Content-Type: application/x-phpwiki;
  pagename=Shells%2C%20terminals%20and%20MSYS;
  flags="";
  author=SureshGovindachar;
  owner=ErikLns;
  version=2;
  lastmodified=1192897215;
  created=1192897215;
  author_id=SureshGovindachar;
  markup=2;
  hits=10610;
  charset=iso-8859-1
Content-Transfer-Encoding: binary

What is an MSYS Application?

 (This is a lightly edited description by Brian Dessent, extracted
 from a mailing list discussion at 09/23/2007 and thereabouts.)

Firstly: a MSYS application is one that uses (links with) the the
MSYS
runtime (msys-1.0.dll), just like a Cygwin application is one that
links
to the Cygwin runtime (cygwin1.dll), and a MinGW application is one
that
links to the native system runtime (msvcrt.dll).  Here the "runtime"
means the library that implements the basic C library and related
support functions.

The C library (libc) is a rather low-level thing and so it is not like
a
regular library in the sense the runtime you pick determines a number
of
characteristics of the application.  In particular, apps using the
MinGW
runtime get exactly what Windows provides and nothing more.  This
means
that there is no support for most POSIX functions such as fork or
select
on fds (and so on.)  Thus applications built to use the MinGW runtime
must be ported to Win32, meaning their source must be modified so
that
they don't use these POSIX APIs that aren't on native Windows.

This porting is a large undertaking and for some applications it is
much
easier to take a different tack -- to use a runtime that provides
implementations of these POSIX APIs so that the source can be
compiled
unmodified.  This is the main goal of Cygwin, to allow any
Linux/POSIX
app to be build without any source changes (or with trivial build
tweaks.)  However, there is the fact that building a Cygwin app means
it's dependant on the Cygwin runtime DLL and is not a stand-alone
binary.  (And a whole slew of other issues that aren't really germane
to
this discussion.)

MSYS is also a runtime that provides POSIX emulation.  In fact it's
just
an old copy of Cygwin (from the 1.3 days) that has been forked and
modified in certain ways.  Specifically, the mount table is moved out
of
the registry and into a file (/etc/fstab) and code has been added to
convert POSIX-filename arguments like /usr/local/foo to
Win32-filenames
like c:/path/to/foo when invoking native Win32 apps.  The whole goal
of
this is to allow building POSIX build tools like bash, m4, sed,
autoconf, perl, etc. which would be hard or impossible to port to
Win32
natively.  The combination of these tools can be used to run POSIX
configure scripts to drive the build process of POSIX software that
uses
autoconf/libtool/automake/etc.  However, the key here is that this
MSYS
environment is just a driver for native Win32 tools such as the MinGW
gcc which produces MinGW binaries.  It is very rare and uncommon to
actually use MSYS to build MSYS apps, and in fact to do this you have
to
install a special environment and use a specially modified copy of
gcc
-- currently a very old 2.95 version.

Now, you mentioned cmd and rxvt.  Those are totally unrelated to the
above discussion; it's just that the MSYS default is rxvt, but you
can
just as well use a native CONSOLE (and in fact it's recommended
due to pty emulation issues.)

More specifically, it's helpful to think in terms of a *shell* and a
*terminal*.  A shell is what interprets commands, a terminal is what
displays things.  These are two different things -- you can use a
shell
without a terminal at all, such as when you run a script with output
redirected.  And you can use a terminal without a shell, such as the
case when you directly invoke a program binary and it outputs to
stdout.

Windows' cmd.exe is a shell.  MSYS' bash.exe is a shell.  rxvt is a
terminal.  The native windows "CONSOLE" is a terminal.  In other
words, you can mix and match these in any combination: you could be
using the bash shell under rxvt, you could be using the bash shell
under
a native CONSOLE.  Or you could be using the cmd.exe shell under
the native CONSOLE.  You could in theory use the cmd.exe shell
under rxvt but this probably doesn't work because of the pty
emulation
issue, but that's an implementation detail and doesn't change the
fundamental separation between shell and terminal.

Brian