Path: 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 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 ***