Where can I get MKS toolkit?
robert.e.o'brien
that MKS toolkit will allow me to do that. Where can I purchase this
software. Thanks.
Bob O'Brien
robert.e.o'brien
Bob O'Brien
* Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
Brad Brown
Thompson Automation provides un*x toolkit which is trully
complete, except for awk which is available as a separate
product.
Reach them @ Thompson Automation (503) 224-1639
--
Brad Brown br...@raid.dell.com "amor vincit omnia"
Dell Computer Corporation 9505 Arboretum Blvd Austin TX 78759 512-339-5037
Brian Smithson
> Thompson Automation provides un*x toolkit which is trully
> complete, except for awk which is available as a separate
> product.
> Reach them @ Thompson Automation (503) 224-1639
How does this compare with MKS in terms of price, "completeness",
and faithfulness to UNIX (to the extent possible in MSDOS-land)?
And which UNIX? System V or BSD? Which shellI(s) does it have?
--
-Brian Smithson
Motorola Inc., Computer Group, Commercial Systems Division
10700 N. De Anza Boulevard, Cupertino, CA 95014 USA, (408)366-4104
br...@csd.mot.com, {apple | pyramid}!motcsd!brian
--
-Brian Smithson
Motorola Inc., Computer Group, Commercial Systems Division
10700 N. De Anza Boulevard, Cupertino, CA 95014 USA, (408)366-4104
br...@csd.mot.com, {apple | pyramid}!motcsd!brian
George A. Theall
> Thompson Automation provides un*x toolkit which is trully
> complete, except for awk which is available as a separate
> product.
>
> Reach them @ Thompson Automation (503) 224-1639
Perhaps I should call but... Do you know what changes Pat Thompson
has made to the toolkit now that Polytron/Sage is no longer marketing
it?
George
---
the...@rm105serve.sas.upenn.edu Dept. of Economics
the...@ssctemp.sas.upenn.edu Univ. of Pennsylvania
gth...@penndrls.upenn.edu Philadelphia, PA 19104
Steve HASTINGS
>How does [Thompson Toolkit] compare with MKS in terms of price, "completeness",
>and faithfulness to UNIX (to the extent possible in MSDOS-land)?
MKS Utilities attempt a total and perfect emulation of UNIX, to the maximum
extent possible, even if it interferes with usability. This is both a good
and bad thing. IMHO, MKS is unusable because they insist on treating
"c:foo" as identical to "c:/foo"; they claim this is more UNIX compatible
and therefore desirable. I say that if I had meant "c:/" I would have
typed "c:/" instead of "c:" and it is a pain to use MKS when you work with
networks and can have long paths on a half dozen drives or more.
Thompson Toolkit attempts to blend the best of the UNIX and PC environments,
and IMHO it succeeds well. It allows you to type pathnames with either
forward slashes or backward slashes, or any combination, but it still lets
you use backslashes as escape characters (like UNIX does). It allows you
to use the arrow keys to recall old commands and edit them, or use the C
Shell '!' syntax ("!v" for the last command starting with 'v') or even a
combination of both. I especially like the way Thompson Toolkit allows you
to type forward slashes in paths being passed to other programs: it can fix
up the command line before it spawns the other program, converting forward
slashes to backslashes and dashes to forward slashes. This is better than
globally altering the SWITCHAR setting under DOS, since it works with all
programs and not just the ones that call DOS to parse their command lines.
(It does not work *inside* programs. This limitation doesn't bother me.)
Thompson Toolkit costs less than MKS, and much less than the Hamilton C
Shell. MKS and Hamilton have features missing from Thompson Toolkit, such
as shell functions. MKS and Thompson Toolkit are both available under both
DOS and OS/2; Hamilton C Shell is OS/2 only. I like being able to write
shell scripts that run equally well under DOS or OS/2, so I am not
interested in Hamilton C Shell at this time.
The Thompson Toolkit is a hacked version of a Bourne Shell. It has many
extensions from C Shell and some from the Korn Shell. It is compatible
enough that I have used it to unpack shar archives. It has C Shell style
aliases, and a future version will have shell functions.
The AWK product, available at extra cost, is an outstanding version of AWK.
The AWK Development Kit includes an AWK compiler that makes standalone .EXE
files that run under either DOS or OS/2. Compiled AWK programs can handle
up to 4 megabytes of data at a time, doing their own virtual memory
(swapping data onto your hard disk) as necessary.
Technical support from Thompson Automation has been outstanding. The
author of the software, Pat Thompson, often answers questions.
Prices:
Thompson Toolkit for DOS $149
Thompson Toolkit for DOS and OS/2 $179
add $50 to get AWK
add $150 to get the AWK Development Kit (including compiler)
You can order it from:
Thompson Automation
5616 SW Jefferson
Portland, OR 97221
503/224-1639
I have no connection with Thompson Automation, except that I am a satisfied
customer who has used the Toolkit for years.
--
Steve "I don't speak for Microsoft" Hastings ===^=== :::::
uunet!microsoft!steveha ste...@microsoft.uucp ` \\==|
Doug Dougherty
>[]
> "MKS Utilities attempt a total and perfect emulation of UNIX
> ... IMHO, MKS is unusable because they insist on treating
> "c:foo" as identical to "c:/foo"; they claim this is more UNIX
> compatible and therefore desirable."
>To us died-in-the-wool Unix experts who don't know much MSDOS and
>aren't very interested in learning, the adherence of MKS to the
>"perfect emulation" goal is highly attractive. I, for one, am
>delighted to have "c:foo" treated the same as "c:\foo".
Could someone explain to me why it is more "Unix-ish" to have C:foo mean
C:\foo instead of C:.\foo? The later is obviously what the user
intends; the former is just a bug.
--
(Another fine mess brought to you by val...@gsbsun.uchicago.edu)
Andrew Klossner
"MKS Utilities attempt a total and perfect emulation of UNIX
... IMHO, MKS is unusable because they insist on treating
"c:foo" as identical to "c:/foo"; they claim this is more UNIX
compatible and therefore desirable."
To us died-in-the-wool Unix experts who don't know much MSDOS and
aren't very interested in learning, the adherence of MKS to the
"perfect emulation" goal is highly attractive. I, for one, am
delighted to have "c:foo" treated the same as "c:\foo".
Different strokes for different folks -- the essence of a free market.
-=- Andrew Klossner (and...@frip.wv.tek.com)
(uunet!tektronix!frip.WV.TEK!andrew)
David Feustel
>Could someone explain to me why it is more "Unix-ish" to have C:foo mean
>C:\foo instead of C:.\foo? The later is obviously what the user
>intends; the former is just a bug.
>--
either way. The result is that about 50% of the time I have to edit
the command and re-execute, at which time the Korn shell command line
editing feature is greatly appreciated.
--
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
EMAIL: feu...@netcom.com or feu...@cvax.ipfw.indiana.edu
Doug Dougherty
>val...@gsbsun.uchicago.edu (Doug Dougherty) writes:
>>Could someone explain to me why it is more "Unix-ish" to have C:foo mean
>>C:\foo instead of C:.\foo? The later is obviously what the user
>>intends; the former is just a bug.
>iThe latter is *not* obviously what this user intends; it is about 50%
>either way. The result is that about 50% of the time I have to edit
>the command and re-execute, at which time the Korn shell command line
>editing feature is greatly appreciated.
I have yet to hear anyone cogently argue *why* inserting the backslash
is someone more "Unixy". Forgetting completely for the moment how DOS
works (although noting in passing that the lack of "drives" in Unix is
something of an annoyance; it makes it impossible to have more than one
current directory in Unix), please explain how the concept of "C:foo"
should map to *anything* in Unix.
Are you saying that in Unix, "foo" should be synonymous with "\foo" ?
(Oops, er, I mean, "/foo")
BTW, don't get me wrong; I'm not a DOS weenie; I grew up on Unix, after
which DOS was a piece of cake. (I pity people who have to go the other way)
But I couldn't resist the above...
Gerard Bras
>[]
How curious. You must ahve interested in learning at one time,
else you would not have become a Unix expert. Seriously, I'm a heavy
MKS user and can tell you it's niether perfect Unix or DOS-friendly.
Other than that I can't live without it.
-gb-
D'Arcy J.M. Cain
>Could someone explain to me why it is more "Unix-ish" to have C:foo mean
>C:\foo instead of C:.\foo? The later is obviously what the user
>intends; the former is just a bug.
It's only obvious to a DOS user. For those that don't know how the unix
file system works, there is no concept of drives. All physical drives
including hard disks, floppies etc. are simply mounted as a directory
on the primary file system. For example if I have a file system on a
floppy with the file "dir1/dir2/file" that I would like to access then
I mount the floppy somewhere on my system. Perhaps I mount it in my
home directory (which BTW is already on a mounted file system) on a
directory called mnt. Now the file name I want can be referred to as
/usr/darcy/mnt/dir1/dir2/file.
Now, how does MKS deal with drives while making it look as Unixish as
possible? I don't know for sure but I suspect that they treat the
various drives as mounted drives on the root and so the most logical
way to deal with C:foo is as if /C/foo was typed where "C" is the
mounted hard disk. Since Unix has the concept of current directory
but not of current drive the concept of a "current" position on a
directory that you are not currently in is counter-intuitive. It
would be like trying to refer to "file" in the above example as
/usr/darcy/mnt/file because the system somehow knows that mnt really
means/mnt/dir1/dir2.
--
D'Arcy J.M. Cain (darcy@druid) |
D'Arcy Cain Consulting | There's no government
Toronto, Ontario, Canada | like no government!
+1 416 424 2871 |
Arthur Rubin
>In article <1991Jun14....@midway.uchicago.edu> Doug Dougherty writes:
>>Could someone explain to me why it is more "Unix-ish" to have C:foo mean
>>C:\foo instead of C:.\foo? The later is obviously what the user
>>intends; the former is just a bug.
>It's only obvious to a DOS user. For those that don't know how the unix
>file system works, there is no concept of drives. All physical drives
>including hard disks, floppies etc. are simply mounted as a directory
>on the primary file system. For example if I have a file system on a
>floppy with the file "dir1/dir2/file" that I would like to access then
>I mount the floppy somewhere on my system. Perhaps I mount it in my
>home directory (which BTW is already on a mounted file system) on a
>directory called mnt. Now the file name I want can be referred to as
>/usr/darcy/mnt/dir1/dir2/file.
As the concept of drives is DOS (TOPS-10, etc.), and has no meaning in Unix, it
makes no sense NOT to use DOS conventions for C:foo. C:foo, C:/foo, and C:\foo
have no meaning in Unix.
--
216...@mcimail.com 7070...@compuserve.com art...@pnet01.cts.com (personal)
a_r...@dsg4.dse.beckman.com (work)
My opinions are my own, and do not represent those of my employer.
Doug Philips
ste...@microsoft.UUCP (Steve HASTINGS) writes:
+ IMHO, MKS is unusable because they insist on treating
+"c:foo" as identical to "c:/foo"; they claim this is more UNIX compatible
+and therefore desirable. I say that if I had meant "c:/" I would have
+typed "c:/" instead of "c:" and it is a pain to use MKS when you work with
+networks and can have long paths on a half dozen drives or more.
*I guess it just depends on what you are used to.* I for one never got
used to a device dependant current directory, so I always used full path
names anyway. I find that it is useful to define shell variables for
commonly accessed directories _and_ files, and as I use two character
names for the commonest among them, that is only one character more than
the supposed win of "c:". As for "unix compatible", it certainly seems
to me that when you name the device you are naming the root directory of
that device...
+Technical support from Thompson Automation has been outstanding. The
+author of the software, Pat Thompson, often answers questions.
I can't say anything about the Tech. Support at MKS because I've never
needed to use it.
-Doug
---
Preferred: d...@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
Shane Dawalt
writes:
> IMHO, MKS is unusable because they insist on treating
> "c:foo" as identical to "c:/foo"; they claim this is more UNIX compatible
> and therefore desirable. I say that if I had meant "c:/" I would have
> typed "c:/" instead of "c:" and it is a pain to use MKS when you work with
> networks and can have long paths on a half dozen drives or more.
>
I won't belabor the point about "c:" vs. "c:/". It seems to have been
beaten around enough.
I can comment on MKS's tech support; in one word: Super. I had a few
problems with the first disks I received. MKS promptly sent me a new
version within a week (must allow for UPS you know). I had another
problem dealing with file management and disk organizers. MKS quickly
explained the problem in a very knowledgable manner. Unfortunately, it
was one of those problems where I was embarrased that I didn't think of
the solution myself. All of this support was obtained through
CompuServe mail. At the time, I didn't have net access and the phone
would have been outrageous.
I am very pleased with the MKS tools. I especially like the awk,
sed and vi tools. They come in very handy. It's unfortunate not many
MSDOS programs allow the '/' for path names. <sigh>
Shane();
--------------------------------------------------------------------------
From the keyboard of: email: sda...@cs.wright.edu
Shane A. Dawalt
--------------------------------------------------------------------------