ajayshah@almaak.usc.edu (Ajay Shah) (10/26/90)
I bought MKS toolkit recently. In case you didn't know, The
Programmer's Shop gives you a educational discount, I paid
something like $125. The toolkit == MKS Shell + MKS Awk + a huge
bunch of /bin programs.
You can install it in several different configurations, each
implies a different extent to which it "takes over" your machine.
The minimal configuration involves leaving your setup essentially
untouched, and filling /bin with 250ish programs which you can
use at will. The maximal configuration is for the MKS shell to
come up through config.sys.
Personally, I hate MS-DOS so I've given over my machine
completely to MKS. The only catches derived from the fact that
I'm a 386 and the installation manual doesn't really talk much
about how to do a good job of installing on the 386. My "best"
solution is pretty weird:
config.sys starts with 386-max as memory manager, and uses
it to put all device drivers into high memory. Last, it
starts up MKS shell as shell=
profile.ksh (the autoexec of the MKS shell) fires a strange
batch file called msdosstart.bat. This chap uses the
386-max programs maxhi and maxlo to load a large sidekick
into high memory. The reason this is done using a MS-DOS
batch file is that it leaves me more memory for the SK
notepad (i can explain further over email).
Goods:
- Awk is fantastic. It's better than the GNU awk.
- I don't like the kornshell (or the bourne shell) but it's a
huge gain over command.com. I say things like q `which td`
all the time and it works!
- The /bin utilities are largely welldone and faithfully
replicate a Unix environment, with some limitations.
- if you have a ramdisk, he makes pipes work through the
ramdisk, which is great for pipes faster than command.com.
- In all, I can't live without it.
Bads:
- the shell commandline editing mechanism is terrible,
- Kornshell is inferior to cshell, IMHO, in many ways,
- it takes a while to move mindsets. Also, running DOS
programs from MKS Shell is sometimes downright irritating.
I sometimes fire a command.com for the purpose :-(
- there are more bugs than I'd have expected from a
commercial package.
- the documentation is good but not great.
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.
- I tried on tar-compress-uncompress on a large file system
and the uncompressed version was different from the
original. It worked correctly on a few other files, but I
can't use it with peace of mind anymore..
- A few other minor shell+/bin bugs.
--
_______________________________________________________________________________
Ajay Shah, (213)734-3930, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________andy@mks.com (Andy Toy) (10/30/90)
I will try to respond to Ajay's comments and the problems which he has encountered. In article <27731@usc> ajayshah@almaak.usc.edu (Ajay Shah) writes: > profile.ksh (the autoexec of the MKS shell) fires a strange > batch file called msdosstart.bat. ^^^^^^^^^^^^^^ That's an amazingly long name on a msdos filesystem :-) > This chap uses the > 386-max programs maxhi and maxlo to load a large sidekick > into high memory. The reason this is done using a MS-DOS > batch file is that it leaves me more memory for the SK > notepad (i can explain further over email). It is typical to run a command.com batch file from the Korn Shell to load programmes that require command.com. However, most problems usually stem from programmes that cannot parse pathnames that have `/' in them so sometimes it is possible to invoke these programmes using the full pathname using `\' from the Korn Shell and still avoid using command.com. i.e. c:\\wp\\wp.exe (double backslashes like in C) or 'c:\wp\wp.exe' (use single quotes) >Goods: [comments deleted] Thanks for the good comments. Now I will try to address the "Bads". >Bads: Note that I do not want to start a flame war about favourite shells. > - 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 :-) > - Kornshell is inferior to cshell, IMHO, in many ways, 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. > - it takes a while to move mindsets. Also, running DOS > programs from MKS Shell is sometimes downright irritating. > I sometimes fire a command.com for the purpose :-( Sometimes, you need to use command.com, but there may be workarounds. Please contact toolkit@mks.com with your problems and MKS will try to solve them. > - there are more bugs than I'd have expected from a > commercial package. By all means, please report them to MKS so that they can be fixed. > - the documentation is good but not great. If you have some suggestions then I would appreciate receiving them. MKS is always on the lookout for good suggestions. >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 programmes because I cannot duplicate this behaviour. I get the error message ``Argument list too long''. Try the same command after booting a ``clean'' machine with no device drivers or TSRs loaded and starting `sh' from the command.com command-line. > - I tried on tar-compress-uncompress on a large file system > and the uncompressed version was different from the > original. It worked correctly on a few other files, but I > can't use it with peace of mind anymore.. Do you have a sample file which will exhibit this problem? I have compressed and uncompressed large files (35 Mbytes) without problems. > - A few other minor shell+/bin bugs. I suggest that you send e-mail directly to toolkit@mks.com so that technical support can attempt to solve the problems which you are encountering. It is important to MKS that we provide good tools for programmers (especially since we use them too). -- Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519-884-2251 FAX: 519-884-8861
feustel@netcom.UUCP (David Feustel) (10/31/90)
Andy, are the problems with M4 that I reported a year ago when it first came out fixed yet? -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
wdr@wang.com (William Ricker) (11/01/90)
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 ***
rja7m@surya.cs.Virginia.EDU (Ran Atkinson) (11/01/90)
In several years of daily use of the MKS Toolkit, I have only run into one bug in the toolkit and when I reported that to MKS, they sent me a fixed version of KSH at no cost within 10 days. I would be more inclined to believe in bug reports if they were detailed -- a posting which just says there are lots of bugs without detailing them is less credible to me. I found one case where there was a bad interaction between KSH and the RAF software used to network my PS/2 to a VMS cluster. MKS Tech Support was really helpful to me in isolating what was happening and understanding how their implementation expected things to work. I eventually got the folks who make the RAF software to acknowledge that it was their software (i.e. not MKS's software) that had the bug. People who are used to CSH will find using KSH awkward, but on our UNIX systems here the KSH (ksh88b is the version) has all of the capabilities of CSH (as distributed with 4.3-Tahoe BSD) including history and job control. Certainly VI and EMACS users will prefer the KSH history mechanism. Your milage will vary. Further discussion of shells probably belongs in comp.unix.shells I have no affiliation with MKS other than as an ordinary (very satisfied) customer.