Path: utzoo!utgpu!watmath!clyde!att!rutgers!mit-eddie!killer!jls
From: jls@killer.DALLAS.TX.US (Jerome Schneider)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MKS BUGS
Summary: A few more bugs in MKS....
Message-ID: <6244@killer.DALLAS.TX.US>
Date: 27 Nov 88 10:38:49 GMT
References: <1361@anuck.UUCP> <507@jc3b21.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 36


Although I e-mailed this to Gerry Wheeler at MKS, I though I would post
it here (in keeping with the spirit of showing both the good and the bad
sides of the toolkit :->).  Here are three more bugs (features?).
 
(I have MKS toolkit Version 2.3b, PC-DOS 3.3, and a clone 386.)
 
 
1)  When using any of the (reserved) option flags inside a ksh string
compare, i.e. [ "str" = "-x" ], a syntax error occurs that does not occur
under AT&T ksh on SysV.3 (killer).  I discovered the problem when trying
to UNSHAR a file with the following script fragment:
 
      if  [ "${1}" = "-c" ] ......,;
 
which was testing for a shell parameter $1 set to "-c" .  MKS ksh seems
to interpret the "-c" string as a -c test for character mode file device 
type and erroneously issued
 
      test: expression syntax error
   
Apparently, the MKS parsing algorithm implements a different precedence
for the = operator and the option flags.  By changing the "-c" to "c" in
the example, the test works properly, so I think this narrows the problem.
 
 
2) inittab ran out of space "file too large" with only 20 lines or so.
Does this mean at inittab can be no larger than one disk sector?
 
 
3) A ctrl-break (SIGINT) appears to break init running inittab.  To set
up a moderately secure rsh login, it would be nice to trap keyboard
activity during init to assure that mandatory programs are run first.
 
If I receive anything definitive from MKS, I'll post to the net.