Path: utzoo!attcan!uunet!pyrdc!pyrnj!dasys1!tneff
From: tneff@dasys1.UUCP (Tom Neff)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MKS Toolkit Question
Summary: Usual thing to check is `switch`
Keywords: MKS with MSC
Message-ID: <7501@dasys1.UUCP>
Date: 8 Nov 88 18:35:05 GMT
References: <4994@whuts.UUCP>
Reply-To: tneff@dasys1.UUCP (Tom Neff)
Organization: Independent Users Guild
Lines: 64

I'm going to post this response instead of mailing it because I
think it's a point all MKS users should remember.

In article <4994@whuts.UUCP> mja@whuts.UUCP (AMMANN) writes:
>I'm having trouble running the MKS toolkit with MSC 5.1.
>when I try to do a simple compile -
>cl file.c
>-
>MSC comes back with error
>LINK : fatal error L1089: D: : cannot open response file
>.
>since I don't even want it to open a resonse file this 
>leaves me a little confused.
>Any  and all help will be appreciated.

Keep in mind that 'cl' is a top-level shell which invokes compiler
phases underneath it via DOS EXEC.  There are two important differences
between many MKS Toolkit setups and vanilla COMMAND.COM setups: the
value of SWITCHAR and the value of COMSPEC.  MKS recommends that you
change your SWITCHAR to "-" (and provide switch.exe to let you do so on
the fly) so that filename and switch syntax is more Unix-like; in
addition, when SHELL=init.exe is specified, the COMSPEC environment
variable is not automatically set to COMMAND.COM.  (MKS's default setup
files include a line to do this, but I'm not convinced everyone is
completely careful about using the right files.)

The SWITCHAR issue is the usual culprit.  There are two ways programs
can handle switches (either when parsing the ones passed to them, or
when passing them to subprocesses): they can hard-code "/" as the
assumed switch character, or they can ask DOS what the current SWITCHAR
value is (via INT 21H service 57H) and use that.  When the parent and
child processes use different assumptions, trouble can result.  For
instance, and most seriously, COMMAND.COM itself uses the second
"smart" method to look up the current SWITCHAR value.  That is, if
'switch -' is in effect, the correct way to spawn a COMMAND-based
subprocess is

	COMMAND.COM -C DIR *.C

instead of the "/C" you would use if the default 'switch /' were in
effect.  So any program wishing to spawn something via COMMAND.COM
*must* actually interrogate SWITCHAR first, if you want to be able
to run it with 'switch -' in effect.  Now, can you guess how many
programs out there in the real world are smart enough to do this?
That's right, you got it. :-)  If you invoke COMMAND.COM with the
wrong switch character, it interprets the {-|/}C as a filename
argument, specifically the search PATH to be used for that invocation.
(Now there's a little known fact, DOS buffs!)  That's why you get
all kinds of strange gunk with 'switch -' under MKS.

My solution is just to set 'switch /' before running problem
programs.  It's not worth having 'switch -' inside an application.
With MKS KSH aliases, you can "box" an application with 'switch'
commands before and after, so retain the Unix syntax at the ksh
prompt itself effortlessly.

The COMSPEC problem is even simpler.  Lots of programs *do* know
to interrogate that environment variable and use it for the exact
pathname of COMMAND.COM to spawn with.  If you don't have it set,
programs tend to croak when spawning.

Disclaimer: I don't know for certain that either of these are
Amman's particular problem.  But the discussion may be of use to
MKS users regardless.