Kermit 95 2.1.3
Update: Kermit is going Open Source as of July 1st, 2011.
This is the Windows version of Kermit: http://www.columbia.edu/kermit/k95.html
There are less expensive terminal emulators, but at $64.00 you
get tremendous value. Kermit is highly customizable, scriptable,
adaptable, robust, flexible.. well, you get the idea. The Swiss
Army knife of terminal emulators.
All this power does not come without cost, however. Learning
Kermit is not quickly done, and mastering it could take weeks,
maybe even longer. Some of the learning curve has been flattened by
a new GUI version that at least gets you started quickly, but even
that isn't as easy and intuitive as it might be, and there are a
few rough spots.
However, I don't think any of the GUI glitches are serious, and
because the command line is always instantly available (just hit
ALT-X) you can always get what you need. Combining the command line
with the GUI (you can, of course just use the command line if you
prefer) is the right way to do it: instant connectivity through the
GUI, without losing any of the command line's power. Command line
access is not something you generally see in any of the competitive
products at all - I'm not even aware of any I have used that have
this. As you also get very powerful scripting ability, Kermit is
hard to beat at any price.
At least at this point, the Kermit GUI probably isn't something
you'd hand out to ordinary users as is. There's just too much power
there and not enough smoothness. However, as a true geek (or even
geek in training) looking to harness this kind of power for your
own needs, or to turn over locked down setups to users, this may be
just what you need. Yes, there is a lot to learn. The GUI is good
enough to get you going immediately and from there you can start
learning the more advanced features. And it isn't that far off from
being usable by ordinary people; the next version may very well be
suitable for that.
What you really need to pay attention to when you first start up
the Kermit GUI is the unfortunately named "Dialer" (most would call
this the "Connection Manager"). This isn't just for dial-up modems
(though that is part of its function). Actually, the dialer is
where you define connections, and how you make connections to other
machines. It's a separate window from the GUI itself, and although
at first I found that odd and a bit unsettling, the idea grew on me
and I now think it's the right idea. A separate window lets you
manage multiple connections from one place, and keeps all that
completely separate from the connection itself.
What you see in the picture above is Kermit 95 running on
Windows XP (which is running under Virtual PC on a Mac as it
happens). The larger blue window is the K95 GUI itself; the Dialer
is the smaller window below it.
The Dialer looks different and has an additional, entirely
different help system for its menu and toolbar. That's because it
was written in an entirely different development environment. See
for an explanation of how this came to be.
Right here is probably a good time to mention that you really
should go read the manual before you dive in. You won't of course,
and neither did I, but you should. But since you won't, I'll say
again that you need to be in the Dialer to start with.
If you've never used Kermit before, you might be tempted to
click on "Quick". That's a simple window that asks you to tell it
what type of connection (Dialup, TCP/IP, SSH, FTP, LAT), where to
go, and to choose something from a "based on" list. Nice idea, but
that's not how it works. The only things in the list to start with
are Templates, and you can't use them for this. Later, after you
have defined a full connection, you can use this "Quick" to quickly
connect to a new host. However, unless this really is a one time
connection that you will not want again, or unless you are really
in a terrible hurry, don't use this because there's no way to save
it for future use - it seems to be a throw-away. That's too bad,
because both alternatives are much more clumsy to use. I think it
would be very nice if "Quick" could use Templates and could save an
entry if you want it to.
I've been told that this ability WILL be in version 2.1.4,
What you have to do now is either make a new connection or clone
one. Making a new connection takes you through every possible
screen, and that's not a bad thing to do at least once to see what
all your choices are, but it's a lot quicker to use "Clone". As you
can clone a Template, that's one way to get a fairly speedy first
time user connection: Clone one of the templates, and then use
"Quick" to make a connection based on that.
Don't put too much importance on the minor clumsiness here. Once
you have your most common types of connections created, it's fairly
quick to clone one, change the host name and login, and be off and
running. You don't even have to come back to the Dialer ever again
if you tell it to put a shortcut on your Desktop for the
connection. For most of us, we'll set up a few connections that we
use every day and hardly ever have to deal with this at all.
Another area of slight clumsiness is editing an existing
connection: although creating a new connection brings you through
every possible attribute screen, editing an existing connection
gives you no choice but to Go back and select the screens
individually, one by one. It would be nice to have the same
"Next/Cancel" buttons here as are present when adding a new
connection. Again, this is an area where the authors are aware
improvement is needed. But it isn't horrible as it stands now: you
have a drop down menu that allows you to choose the screen you want
to go to, and as long as you know where what you want to change is,
you can get there quickly. And how often are you likely to be
making changes - once you have a particular connection set up, it's
probably not going to need tweaking. These little quibbles are
minor and will have little or nothing to do with your day to day
use of Kermit.
One note on the GUI: in some places, dialog boxes that you would
expect to be able to click away with a single click sometimes
require a double click. If something seems "stuck", remember that.
This is an unfortunate side effect of the laudable effort to make
this a cross-platform application.
By the way, the help manual is local to your machine but can
also be accessed on-line. It's still HTML locally, which I think is
much preferable to Windows style help files. However, that does
limit your ability to search, so you'll probably want to use the
on-line version when possible: http://www.columbia.edu/kermit/search.html
There's also "Context" help listed in the Help menu. You might
expect that would mean that you can highlight a command you are
trying to use and jump right to that section, but that's not what
it is. What they mean by "context" is whether you are in command
mode or in the emulator: choosing context help brings up
appropriate keys that you can use in the mode you are presently
Another menu choice that may not be immediately obvious is
"Locus". The manual explains it:
Locus refers to the target of file management commands when Kermit
has a connection to a server on another computer. Historically,
commands such as CD, DIRECTORY, DELETE, RENAME, and MKDIR have
always acted locally in all Kermit programs. To ask a remote server
to do these things required a REMOTE or "R" prefix: e.g. REMOTE CD
When the FTP client was added to Kermit in 2002, this behavior
seemed unnatural to users of text-mode FTP clients. Thus the notion
of Locus was introduced: Local means that unprefixed file management
commands are executed on the local computer; Remote means they are
sent to the remote FTP or Kermit server for execution. By default,
Kermit switches Locus automatically every time you make or break
a connection, depending on what kind of connection it is. When you
make an FTP connection, Kermit switches its Locus to Remote. When
you make any other kind of connection, or when you break any
connection, its Locus switches back to Local.
Dozens and dozens including Linux, Wyse and SCOANSI. And accurately
done: see http://www.columbia.edu/kermit/k95gallery.html
for some screen shots.
It's unlikely that you will need anything that you won't find
here. If you did run across something unusual, you have complete
control of what keys send and mean. You can redefine function keys,
change behavior: whatever you need to do. Only some of that is
available from the GUI menus; you will need to drop to command mode
for complete control. But that is COMPLETE control - while you may
need more knowledge of the host machine to have the necessary
information, if you do have it, you can mold Kermit to whatever it
is you need. That's power.
It's important to mention that Kermit supports Unicode. Kermit
has extensive support for character sets and the ability to convert
among them. Take a look at http://www.columbia.edu/kermit/glass2.gif
The initial creation of a connection (from the Dialer) leads you
through fourteen screens that let you define just about anything
you could ever imagine, but one sometimes useful feature is
missing: at some sites, I want to prevent users from just closing
their terminal window without properly exiting their session.
That's a feature other terminal emulators have added in recent
years. Kermit does have a menu setting that can ASK you if you
really want to disconnect, but I'd like that "X" button disabled
entirely. Interestingly, this version does support creating
connections that are locked down with no menu or tool bar, which is
a very nice feature. If they would also turn off the ability to
close the Window while connected, that would cover everything.
But everything else is there: screen colors, font sizes,
authentication methods, logins, the download directory, linewrap,
scrollback size, how to handle file name collisions, environment
variables, tcp buffer sizes, socks and proxy servers, key maps,
printer control (even conversion to Postscript) and of course
Kermit, FTP, and XYZMODEM file transfer
You'll undoubtedly notice that both "scp" and "sftp" are
conspicuously missing. The authors of Kermit explain why at
but I personally think they need to lower their standards and go
with the accepted protocols. I am not going to stop using scp both
because I like it and because I may not have the desire or even the
permission to install Kermit on the hosts I need to work with. For
many years prior to this release the Kermit authors had a similar
attitude toward ssh; they didn't see the need for it in Kermit. I
thought they were dead wrong then, and I think they are just as
wrong about this. They do say that they intend to add these
features in spite of their dislike for them.
Their reasons for preferring Kermit as a transfer protocol go
way beyond the obvious fact that it's their baby. Here is some of
what they have to say:
- It's intrinsically platform- and transport-neutral.
- It's adaptaptable to hostile, unreliable connections.
- It's equally adaptable to high-performance error-free
- It proudly deals with platform differences, converting both
record format and character set of text files. SCP, SFTP, and
friends don't do either one. I'm not aware of any protocol other
than Kermit that converts character sets.
- It switches between text and binary mode automatically on a
- It can move directory trees between unlike platforms (Unix,
- Unlike FTP, it is symmetrical. Timestamps, permissions, and
other attributes are conveyed in both directions -- upload and
- It can do "atomic file movement" for transaction
Their concerns about SSH in general are mostly arguments
concerning compromised keys. A very good article about Windows
security in general talks about this: http://www.columbia.edu/kermit/safe.html
and it's worth reading for any Windows user anyway.
Another useful link is their comparison of ssh clients: http://www.columbia.edu/kermit/winsshclients.html
One omission from the GUI Windows version is the ability to
upload files from a terminal session. You don't get a GUI menu
choice that would let you pick a file and choose your method
(zmodem, kermit, etc). However, you can simply do ALT-X and use
SEND from the Kermit command prompt. Or, if the Unix host is
running Kermit, use "kermit -s file". In either case, that may be
all you need to do. Downloads and uploads can be completely
automatic: for example, I did "sz file" while logged into a Unix
host and Kermit automatically received it. When I did a SEND from
the ALT-X prompt, the Unix host happily recieved it without any
intervention on my part also. Can you live without a GUI pick
dialog to upload files? I can, but I do think they need to add this
in a future release.
If the receiving computer doesn't have Kermit, you can probably
bootstrap it: see http://www.columbia.edu/kermit/gkermit.html#boot
Compatible software is available for Unix (SCO, Linux, BSD,
Solaris, etc) from http://www.columbia.edu/kermit/ckermit.html
including hundreds of prebuilt binaries that you can download from
FTP and HTTP file transfer
These are the places where you will really appreciate Kermit's
power. Forget the GUI for this: this isn't a graphical, drag and
drop client and may never be. You can use the Dialer to define an
FTP connection, but that's almost (but not quite) useless, since
the GUI really doesn't support these to any degree: this isn't a
GUI drag and drop for FTP. Perhaps someday they can include a nice
GUI file transfer that can use FTP, HTTP, Kermit, Scp and
everything else, but that's a big project, and the real value of
Kermit in this area is scripting. This is where Kermit shines.
Configuring FTP in the dialer does have value : you can use it
to easily set the many possible authentication and encryption
options. You could also put a script in the login box, either as
immediate commands or to run an external script file.
for some ftp specific scripts, and the Script Library
has an incredible array of other scripts that can help you solve
all manner of nasty or annoying problems. You really need to look
at the manual to appreciate all the power here, but you can also
get a good idea just by using "?" at the command prompt:
[C:\Program Files\Kermit 95 2.1\] K-95> ftp mput ? Filename, or switch, one of t
/after: /larger-than: /server-character-set:
/array: /listfile: /server-rename-to:
/as-name: /local-character-set: /simulate
/before: /move-to: /smaller-than:
/binary /nobackupfiles /tenex
/command /not-after: /text
/delete /not-before: /transparent
/error-action: /quiet /type:
/except: /recover /update
/filenames: /recursive /unique-server-names
Full documentation is at http://www.columbia.edu/kermit/ckermit80.html#ftp
Of course Kermit still supports modems. In addition to dial up
connections, it can also handle numeric and alphanumeric paging.
Remember that this is all scriptable; while you probably wouldn't
have much use for interactive paging, scripted paging is an
entirely different story.
Host Mode and WIKSD
Kermit can also be a server. This isn't GotoMyPC or PCAnywhere
and it's not meant to be. This is to transfer files (there's also a
facilty to read and send messages). If you are running NT or XP,
you would use WIKSD, which is really just Kermit 95 running as a
service, and limited (by design) to file transfer while doing so.
Both of these are authenticated access: the would be user has to
Unlike many companies nowadays, Kermit has more than reasonable
support. There's no charge for email support
(firstname.lastname@example.org), and they usually respond very
quickly. Additionally, there is a newsgroup
(comp.protocols.kermit.misc) and of course the website : http://www.kermit-project.org/support.html
Some user comments: http://www.columbia.edu/kermit/tsreviews.html
Kermit resisted SSH firmly. You'll find leftover hints of their attitude at their telnetd page ("The Telnet and FTP protocols have options that provide for strong authentication and encryption just as SSH does.").
That's why I was surprised to see ssh support, though it was still obvious that Frank had a bad taste in his mouth about it.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2012-07-12 Tony Lawrence