4 ms·
Before it was common for a home PC to have IP connectivity (via SLIP, PPP, etc), you needed a program to connect to your modem, dial a terminal session into a
by tyingq 5y ago
Before it was common for a home PC to have IP connectivity (via SLIP, PPP, etc), you needed a program to connect to your modem, dial a terminal session into a remote server, handle file transfers,etc.
Sometimes these programs bundled both the terminal/dial up and the file transfer functionality. Other ones were terminal/dialers, but would spawn a separate file transfer program.
Kermit was the bundled type...both the terminal/dial and file transfer was built-in. It was also more scriptable than a lot of other solutions...it had an embedded script language with send/expect functionality. So, for example, if you had a bank of ethernet connected modems, you could script whatever commands where needed to connect to them and dial. Or you could connect and script against the unix (or other) shell on the remote end. It's even handy for this type of thing today, as it can use ssh as the connection instead of dial up.
It was also the most portable program of this type, with versions that would run on MS/DOS, Windows, Unix, IBM mainframes, Multics, CPM, etc.
I used it quite a lot because I was a unix admin, and our work didn't offer SLIP or PPP dial-in. So, I could use kermit to run batch jobs to connect, download my recent work, maybe some usenet news data, etc. Or, just use it as a terminal program at home to get a unix shell prompt from a computer at work, upload files, and so on.
- tssva 5y agoKermit supported much more than serial connections. It supported DEC LAT, telnet/telnet SSL and rlogin natively. Through external apps it supported TN3270, TN5250 and ssh.