ANSI terminal emulators for linux

I use minicom. It is, oddly enough, a command-line utility -- but none of the graphics-based ones that I've tried are good plain-old terminals. I'd prefer something that has a point-and-click interface (with a window to type in), but none of those touch Minicom for ease of use, even including the fact that I don't like having to memorize all the stupid control-this, control-that to make it work (I just remember ctrl-X to get a command line, and H to get "help", which is a menuing system).

minicom -b 38400 -D /dev/ttyUSB0

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

I recommend ckermit, which isn't a terminal emulator, just a rock-solid serial comm program. You can run it in any terminal emulator you want (linux console, xterm, aterm, rxvt, urxvt, gnome-terminal, kterm, screen, ...)

I prefer the Unix approach of one-function-one-program -- separating the serial comms from the terminal emulation. But, if you want something that's pointy-clicky-all-in-one, there's always putty:

A lot of people use minicom, but I find its UI utterly abhorrent.

--
Grant Edwards               grant.b.edwards        Yow! I brought my BOWLING 
                                  at               BALL -- and some DRUGS!! 
                              gmail.com

This throws me, and I'm sorry I didn't mention it. In Windows-land, a "terminal emulator" is a program that makes your computer emulate a serial terminal. In Unix-land, a "terminal emulator" is a program that runs under X and emulates the serial terminal that the operating system was originally designed to talk to. So, they're two entirely different things with the same name.

The thing known in Windows-land as a "terminal emulator" is known in Unix- land as a "serial communications program". The Unix-land "terminal emulator" is the Windows-land "DOS window" or perhaps "command-line window".

I tried putty and really didn't like it. I can't remember why, just that the features available didn't make me happy.

I'll have to try ckermit. Minicom works for me, but only because I have a basic strategy of getting into the "help" menu and navigating (sometimes with lots of iteration and cussing) to what I need.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

In CKermit it's ctrl-\ to get to the ckermit prompt, and then it's all commands like "set baud 9600" "set parity none" etc.

IMO, the easiest way to use ckermit is to define an initialization file for your most commonly used configuration and then write a small shellscript for each configuration that invokes ckermit with the proper initialization file.

My default config file looks like this:

set port /dev/ttyS0 set baud 115200 set flow none set parity none set carrier-watch off log session connect

So that's what I get if I just type "kermit".

--
Grant Edwards               grant.b.edwards        Yow! Should I get locked 
                                  at               in the PRINCICAL'S 
                              gmail.com            OFFICE today -- or have 
                                                   a VASECTOMY??

Well, they're not entirely different. Both of them emulate a vt52, or vt102, or ANSI, or Wyse50, or Tek4014[1], or whatever inside a graphical window.

The Windows version _also_ handles serial-port (and often network) communications.

The X version just talks to a pty (which is sort of a dumbed-down minimalist virtual serial port that connects two programs together) and leaves the actual serial-port stuff to be handled by whatever is connected to the other end of the pty. Then you can connect the other end of the pty to ckermit, tip, cu, telnet, ssh, rsh, nc, or anything else you want to use to provide a byte-stream connection to the applicatoin that's expecting to talk to a "terminal".

[1] Yes, xterm will still emulate a Tektronix 4014 storage-scope vector graphics terminal [except, sadly, there's no bright-green flash when the screen is erased -- I've always wanted to add that...]

--
Grant Edwards               grant.b.edwards        Yow! It's some people 
                                  at               inside the wall!  This is 
                              gmail.com            better than mopping!

Like Don, I use screen (with Linux, rather than BSD). Using different colours for the windows is not a bad idea at all.

screen /dev/ttySerial_hub2 115200

It doesn't get much easier than that. (It is not quite as flexible in its serial parameters as something like minicom - but you don't usually need that.)

A /really/ nice thing you can do in Linux is use udev rules to set up rules for USB components. For example, I have a 4-port hub connected to one of my PC's USB ports. I have some lines in a udev rules file like this:

KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.0/*", SYMLINK += "ttySerial_hub2" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.1/*", SYMLINK += "ttySerial_hub2b" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.0/*", SYMLINK += "ttySerial_hub3" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.1/*", SYMLINK += "ttySerial_hub3b"

Any USB to serial converter I attach to port 2 of the hub turns up as device /dev/ttySerial_hub2, as well as the standard /dev/ttyUSB0. If it is a two channel converter, the second one is "hub2b". I have similar rules for physical ports 1 to 4 on the hub.

You can also have rules that match on serial number of the converter regardless of the port, exact type of converter (TTL, RS-232, RS-485, etc.), or combinations. Rules can make multiple symlink names, change access permissions, and so on.

It is vastly easier than Windows assigning different COM port numbers for each device and changing it according to the physical port, the hubs, the weather, etc., so that you never know if you should be using COM94 or COM16.

Linux is a bit odd in that a command window *is* a terminal emulator. It just isn't connected to a serial port.

I ran into this problem when I was working with a Raspberry Pi to use as a remote interface to an embedded MCU board. I seem to recall miniterm had some problems with the end of line character conversion. I can't recall what I used, it may have been picoterm. The ones I found were all a bit crude and every single one had some sort of significant limitation.

I don't recall what I used to use under windows, but in the "old" days it seemed there were plenty and they worked well. Now it seems to be harder to find them and they don't work as well. By that I mean the user interface is not as good.

--

Rick C

Am 02.11.2016 um 19:21 schrieb Tim Wescott:

Hmmm... I've only ever seen those called "terminal program" --- a breed including what was arguably the most broken pre-installed Windows utility ever, aptly nicknamed "Hypoterminal", because there was really nothing "Hyper" about it.

There are terminal emulators like that on Windows, too, e.g. MinTTY or the ported rxvt. And if all else breaks, one can always run X11 on Windows, including xterm.

PuTTY by comparison is a multi-tool serving as a terminal program, telnet, rsh and ssh clients, and a Unix-style terminal emulator, too. It really has to pack all those into one tool to be useful, since Windows itself provides none of them. Even Telnet is absent in a normal install.

Windows itself calls them "consoles", and it interjects its own native terminal emulator automatically whenever a console application (i.e. a normal C program with a main() function) is executed by anything that isn't already running in a console. It has to do that because Windows GUI programs otherwise have no connection to any console, i.e. no "controlling pty".

Wow, I didn't know screen would talk directly to serial ports.

The description of that feature is hidden 2000+ lines into the man page under the heading "Window Types". And I've been using screen for a _long_ time (30 years) -- since before Linux was born. I first used screen when I ported it to a 16-bit Unix v7 clone called Coherent that I was running on an 8MHz IBM-AT with an 80268:

[And before I could port screen to Coherent, I first had to write a pty driver, since Coherent didn't have ptys at the time.]

The interesting thing about screen is that it _is_ a terminal emulator, but it doesn't run in a graphical window (like xterm or putty), but instead runs on top of another terminal (either an emulator or a real serial terminal). IOW, it emulates a VT1xx/ANSI terminal on top of whatever type of termial you actually have. Back in the day, if you happened to be using some oddball non-ANSI terminal, and wanted to use a program that was hard-wired to expect an ANSI terminal, screen was a life-saver.

The multi-window and session-disconnect/reconnect is pretty cool too...

--
Grant Edwards               grant.b.edwards        Yow! -- I love KATRINKA 
                                  at               because she drives a 
                              gmail.com            PONTIAC.  We're going 
                                                   away now.  I fed the cat.

I can't claim any credit for finding it on the man page - I read about it on a website somewhere, and realised it does exactly what I need for a terminal emulator on a serial port. I had been using screen for a decade or so before I found out that it can talk to the serial port.

And you can still do normal "screen" things with it while using a serial port, like have multiple virtual windows, connect to it from a different computer in parallel, or do logging.

I think you are the second person I have ever heard of who ran Coherent!

One of the main things I use "screen" for is when connecting by ssh to a server. I can happily run long-term tasks within screen - it doesn't matter if my ssh session dies, or if I want to move between by office machine, my home machine, my mobile with JuiceSSH, or whatever.

I like ckermit too but considering I first used it back in 1986 and the UI hasn't changed much I wouldn't recommend it to anyone not already familiar with it. Same goes for Emacs whose serial-term is fine for basic use.

So I guess for ease of use for someone coming from Windows it's putty.

Thanks for all the helpful suggestions, guys.

Cheers

--
Syd

No (IMHO anyway :-)). I think you are confusing the application (which is designed to emulate a physical terminal) with the back end connectivity options implemented within that application.

For example, PuTTY on Windows only has remote connectivity (network and serial) options available due to Windows limitations.

PuTTY on Linux also has that but it also has an additional back end connectivity option which allows direct connection to a pty and hence to a shell running on the local machine. (This is implemented using the pterm program if you didn't already know about it).

Likewise, various other Linux based terminal emulators just implement the pty back end connectivity option only.

This doesn't change the fact that these programs all do the same thing, which is to emulate a physical terminal but with some additional optional features (such as long terminal window lengths) thrown in.

BTW, many of those open source terminal emulators are absolutely lousy when it comes to fully and accurately emulating a VTxxx terminal.

A good test is to try them against vttest but I've found an even better test is to try using VMS with them. (VMS is an operating system developed by the company (DEC) which gave us the VTxxx standards in the first place.)

Try using a DEC editor (such as EDT or EVE) with many of these open source emulators and they fall down hard. One of the major problems is that properly emulating a terminal involves emulating it's keyboard as well as it's display (so that, for example, pressing Num Lock on a PC keyboard would give you the PF1 keyboard escape sequence) and many of them simply don't bother with the keyboard part of the emulation.

When I've looked at them in the past; some of them couldn't even render the EDT/EVE screen correctly and this was before you even got to trying out the keyboard. The only open source successes I have had here are with xterm and PuTTY and both of them required some configuration (especially xterm) before they could be used with VMS systems correctly.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

IMO, the biggest advantage of screen is that it is NOT "just a terminal emulator".

Have a single (text) console? (e.g., boot single user on a box that has been configured with ONLY the primary console) Screen lets you start multiple "sessions" so you can do several things at once -- hot switch between them without waiting for one to complete: 1# ls -alR / | gzip > /ls-alR.gz meanwhile: 2# tail -f /ls-alR.gz and: 5# cd ~me; tip MyDevelopmentTarget plus: 3# cd ~me; vi MySourceCode.c

*Some* "terminal emulators" will let you escape from the current "session" (without dropping the connection) to rummage around in the shell. But, your actions then scroll the previous "session" contents off the display. Hot switching between sessions lets you, for example, scroll down to the point in session 3 where the MySourceCode.c initializes the target's hardware; then hot-switch back to session 5 to interact with that target using the information gleaned from session 3.

And, this stuff continues to work in the same way when invoked from one of *multiple* consoles (if the local system is configured as such) *or* from an xterm(1) -- or multiple xterms!

screen(1) is my all-time favorite (in terms of practicality) tool in terms of capabilities that it presents vs. implementation costs!

I've also used kermit for decades. Another option is to simply use screen or if I need some of the kermit features I run kermit under screen. Then multiple users (logging in to the same user) can use use the same screen session.

//Petter

--
.sig removed by request.

So do I. Some may find the initial user interface a bit clunky, but it's solid right up to 115K and with no flow control ime, much as is Teraterm under windows.

Currently have it on a laptop, running under FreeBSD, but just the same results on Linux...

Regards,

Chris