Re: Using MSYS as Emacs shell

On Saturday 10 April 2010 14:50:26 Vincent Torri wrote:
> > $TERM isn't really a good choice for identifying an MSYS
> > environment, (it is too ubiquitous); something MSYS specific,
> > such as $MSYSTEM, would surely be a better choice.
>
> why is MSYSTEM better ?

$TERM identifies capabilities of the underlying *terminal*, as 
configured within a termios or termcap database; it is not specific 
to the operating system.  (FWIW, several years ago I was supporting 
a process control system hosted on SunOS, via telnet access from my 
local MSYS host.  To get proper operation in the MSYS client, I had 
to define the `msys' terminal type in the SunOS termios database.  
If I were to interrogate $TERM in such a telnet session, I would 
have seen `msys', but the host OS was SunOS; your assertion that 
$TERM == msys identifies MSYS as the host OS would have failed 
comprehensively in this scenario).

OTOH, $MSYSTEM identifies a property of the OS itself, so is a better 
choice.  However, even this is not an ideal choice, because:--

  1) It isn't guaranteed to exist; (it is an MSYS peculiarity).
  2) It can be modified by the user, so may yield false results.

What is really needed is a mechanism to interrogate the output from 
`uname', (perhaps specifically `uname -o' or `uname -s'); use of an 
environment variable related to this is simply more convenient than 
spawning the `uname' command to inspect its output.  (Note that 
changing the value of $MSYSTEM affects the output of `uname -s').

In this particular case, $OSTYPE would seem to be a better choice 
from among the bash shell's predefined environment variables, but it 
comes with a gotcha: it isn't normally exported.  Thus, if you want 
to use it in the manner required for this purpose, *you* need to 
ensure that it is exported from your top level shell.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev