🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.msdos.programmer
Article #2878

Re: Review of MKS toolkit

#2878
From: William Ricker
Date: Wed, 31 Oct 1990 20:24
133 lines
6853 bytes
I enjoyed andy@mks.com (Andy Toy)'s reply; wish I'd seen 
article <27731@usc> ajayshah@almaak.usc.edu (Ajay Shah), which probably
expired before I saw it.  (We've got expiration set too high due to disk
space :-(.)

I am a satisfied user of MKS Toolkit; I won't touch a DOS machine
without it for very long.  I'm not such a died-in-the-wool Unix bigot
that I insist on loggin in to my DOS machine, though; I use
"Configuration #1", where the DOS uses Windows3 and COMMAND.COM as the
primary command interpreters.  I typically have one KSH window open
and two COMMAND.COM windows open (one of which contains either a
Micro-Emacs or a shareware outliner on top of a spell-check TSR) as
well as my Windows Apps (like Terminal -- which I use to read
mail/news).  I'm happy typing /path/ in one window and \path\ in the
other. But then, I happily switch between VI and EMACS routinely, too.
I'm known to be weird.  I even run some MKS commands with mixtures of
/ and \ from COMMAND.COM at times ... just have to learn which is which.

If I could get a Requisition for a site license  and stuff KSH down my
colleagues' throats, I'd probably happily use Config#2 or #3, with KSH
the default command interpreter, on my PC and Config#4 on our demo
machine, just to provide home directories.  I don't expect to win this one,
since I'm the only tool-collector in the bunch. 


>> Bads:
> Note that I do not want to start a flame war about favourite shells.
I'll try to avoid fanning the embers...

>>	- the shell commandline editing mechanism is terrible,

>If you are used to VMS, OS/2 or DOS command-line editors then this is
>true for you, but if one's fingers are already accustomed to vi or emacs 
>editing commands then it is great :-)

It is compatible with KSH on SCO Unix V, which has VI and choice of two
EMAC modes.

>>	- Kornshell is inferior to cshell, IMHO, in many ways,

as a user interface or as a script language?

>That's each person's opinion, like you said, but I certainly prefer the
>Korn Shell over the Bourne (sh), C (csh) or bourne again (bash) shells.

The major advantage I saw to CSH was when I was on BSD4.2 Unix was as
a user interface shell.  The superior Job Control features of CSH were
supported by the OS.  CSH on Unixes without Job Control in the OS --
or on DOS, without process control at all -- is markedly less
outstanding.  Bourne (SH) shell was always the winner for programming
shell scripts for me, although I did program a number of scripts in
CSH which were mostly pipeline macros, which I've converted to KSH.
KSH's history editing supplies the other major capability that SH
lacked and CSH has.

>>	- it takes a while to move mindsets.

I've heard this before, but only rarely found it so.  If you find
each program's metaphor (or its programmer's mental model), and
*expect* these to be different, you may find that you automatically
"load" the relevant metaphore/model with the software.


>Sometimes, you need to use command.com, but there may be workarounds.

I have run COMMAND.COM under SH, and viceversa.  Easiest, by far, is to
run both concurrently under Windows-3, which on a 386 is a real operating
system.  When I've stopped windows (it autoexec's for me), I'll nest
command->sh->command as necessary -- and conservatively: if I'm not certain
a given command will accept args they way I want to type them, I'll
push one level of interpreter to get the one I know can feed it straight.
No :-(, just reasonable paranoia.


Of course, the clean way to get Unix commands to work where DOS programs
run is to get a 386 Unix with a good DOS BOX -- almost all do -- and run
a DOS partition on disk and as a process.  Then you get CSH and KSH
(although SCO's CSH is a little broken, last I saw; my scripts that rely
on && working as documented, like it does on 4.2Berklix and Ultrix, 
fail miserably; also, I noticed some oddities in AWK under SCO Unix V...)

>>	- there are more bugs than I'd have expected from a
>>	commercial package.

eh. I've encountered fewer Bugs in MKS's port of the unix toolkit in
three years than I've found in SCO's in three months.

>>	- the documentation is good but not great.

The documentation is well above the pitiful average of the market they
address -- unix toolkits.  Compared to a Spreadsheet's, no unix
toolkit's documentation, looks good.  So? The DIAGNOSTICS, FILES,
PORTABILITY, and LIMITATIONS sections are unexpected, useful, and
apparently correct.  To damn with faint praise, it is GREAT for a unix
toolkit.  . . .  I am not compentent to address whether the Common
Questions and Quick Overview sections are sufficient to bootstrap a
DOS user without unix experience; it might not be sufficient in volume
and organization to provide a full tutorial on the toolkit to someone who
doesn't know what they wanted it for.

>If you have some suggestions then I would appreciate receiving them.
>MKS is always on the lookout for good suggestions.

Put an introduction to SHell programming book (someone else's) on your
order sheet, and recommend it to anyone who orders an MKS Toolkit who
isn't a Unix user as well as a DOS user.

>>Bugs I found:
>>	- If you exceed the size of the commandline he can deal
>>	with (max = 8192 instead of microsoft's 128), he hangs.  In
>>	my /bin which has a huge number of progams, ls *.exe hangs
>>	him.

>You may be encountering some unusual interaction between some
[motherpie deleted]
I certainly wouldn't rely on bug reports in a mail message which mentions
using memhi/memlo & TSRs until it has been replicated without them.
[further flammable comments of my own suppressed.][

All unix derived software has the basic flaw of fixed input buffer
sizes.  MKS is not imune to or alone in this predicament.  They do at
least publish the buffer sizes in the manual (as noted above), which
is better than many.  I would certainly appreciate versions of SORT &
AWK which would accept a flag to authorize using the less efficient
GETMEM() to ensure buffers never overrun.  (I like using 'paragraph'
mode, to sort or select paragraphs -- which frequenly hover around
1k, the buffer size. in at least an earlier release of MKS toolkit.)

Cc: toolkit@mks.com  andy@mks.com ajayshah@almaak.usc.edu
-- 
/bill ricker/
wdr@wang.com a/k/a wricker@northeastern.edu
*** Warning: This account not authorized to express opinions ***
Technical Details
Message-ID: <1990Oct31.202428.13765@wang.com>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!wang!wdr
References: <27731@usc> <1990Oct29.214856.11851@mks.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!wang!wdr
From: wdr@wang.com (William Ricker)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Review of MKS toolkit
Message-ID: <1990Oct31.202428.13765@wang.com>
Date: 31 Oct 90 20:24:28 GMT
References: <27731@usc> <1990Oct29.214856.11851@mks.com>
Organization: Wang Labs, Lowell MA, USA
Lines: 133