Decent Terminal Emulation on Mac OS X?

Drawoc Suomynona asks: "After settling into Mac OS X over the last four months, I'm generally impressed. However, due to the sort of development work I do, I spend a great deal of my time in a terminal. Unfortunately for me, decent terminal emulation seems to be one area where Mac OS X is quite lacking. What's your answer to the state of terminal emulation on the Mac?" Drawoc summarizes the currently available offerings and their drawbacks, below.

"Take, for instance, the following options:

• Apple's Terminal is slow (though performance has been better in 10.2.x), doesn't support xterm mousing, and for some reason refuses to send PgUp/PgDn through to any applications running in the terminal (gah!). Sure, transparency is nice, and with some hacking about (when was the last time you had to force "stty erase"?) you can get decent enough color xterm emulation, but... what's with the lack of PgUp/PgDn?
• The open source iTerm is slightly better, but, it's awfully slow (it grabs as much as 30% of the CPU per terminal instance... now imagine a full-screen vim session at 1600x1200... it's utterly unusable). It also neglects to support xterm mouse reporting.
• The closed source GLTerm ($10) is probably the best of the three "native" options, from a certain perspective. It manages to sidestep the CPU usage/UI responsiveness issue by rendering the entire terminal using OpenGL (yes, the characters are actually textures on GL primatives). It supports xterm mouse reporting. However, font choices are limited, it works only on supported video cards, and it has a very annoying "fuzzy text bug" if you set your terminal to the wrong size.
• Finally, you've got xterm :) But, it means you need to run X11 (either XDarwin or Apple's X11) and it doesn't integrate as nicely into the OS X workflow..."

So, is there a secret terminal port from NeXTSTEP lurking in the pocket of some intrepid young hacker, who is, as I write this, poised to lead us to salvation?"

Comments

Fink

[qlippoth]

Fink has a handful of terminals ported to OSX. You've still got the issue of having to run X11 though.

http://fink.sourceforge.net/pdb/section.php/x11

you could use Rxvt

[goombah99]

fink install rxvt

rxvt 2.7.8-2 VT102 emulator for X11
rxvt-ml 2.7.8-2 VT102 emulator for X11 with multi-language support
this too is X windows unfortunately.

personally I actually like apples terminal with one scarey exception: it runs in a single process so if the terminal app crashes you lose ALL of your terminals! yikes.

Re:you could use Rxvt

[bobthemonkey13]

Look into a UNIX utility called screen. I'm not sure if it's included in OS X, but I use it all the time on Debian and OpenBSD and it's wonderful. You can detatch and reattach sessions, so if Terminal crashes, you can just open another one and run screen -R to pick up where you were. It also supports creating multiple windows in the same terminal, and a whole ton of other features that I haven't even tried yet. I've even used it to start a process locally, then ssh in later and automagiclly take control of the process. It should compile without problems on OS X; there might even be binaries available.

NEXTSTEP terminal.app

[macmurph]

Here's a screen shot of the NEXTSTEP Terminal.app

http://www.levenez.com/NeXTSTEP/Terminal.jpg

PuTTY

[zsazsa]

Everyone's favorite SSH/Telnet program for Windows, PuTTY, is a possible future option. A MacOS port is forthcoming. If you're brave, preliminary support is in CVS right now.

(In other Non-MacOS-related PuTTY news, you can also get a PuTTY-based xterm replacement for X if you fancy its emulation better: pterm).

TERM environment variable make a difference

[payam]

The TERM environment settings for Terminal.app make a big difference in its behaviour. Normally with Terminal it's useful to have the TERM environment variable be 'xterm-color'. This will enable lots of interesting things, amongst them ANSI color. But, as described, this has it's drawbacks, including the fact that scrollback doesn't work as expected. Sometimes it's useful to launch any apps that need that functionality prefixed with 'TERM=vt100'. I run screen this way( 'TERM=vt100 screen') and it works much better as a result.

Alas, this doesn't affect speed but it does enable improved functionality.

Terminal crashes and character encoding

[gidds]

if the terminal app crashes you lose ALL of your terminals!

I hit this one a LOT. It's a real annoyance.

Why, I hear you ask? Well... [fx: takes a deep breath] Most of my text files use the Windows Latin-1 encoding (the same as the default ISO Latin-1, but with curly quotes and other useful control characters in an otherwise-unused range). No problem for the Terminal: you can set the character encoding in Window Settings->Display.

I use the vi editor; you can tell it the character encoding through the $LC_CTYPE environment variable. The only problem is that although Mac OS X comes with several character encodings (in /usr/share/locale), it doesn't come with one for Windows Latin-1 (aka CP1252). So I've created my own (with the mklocale(1) command. I've even submitted the result to Apple in the hope that they might include it with future versions... though I haven't heard anything back.)

So, with both Terminal and vi set to use the right encoding, it all works: I can see all the extended characters, and edit them in the usual way. EXCEPT that there's some bug or incompatibility lurking there. Every so often, when I'm editing in vi, the Terminal will suddenly quit for no reason. It happens often enough to be fairly sure that it's related to the extended characters and to vi - it's never happened when editing plain 7-bit ASCII files, nor when using extended characters in the shell. I suspect it may be related to extended characters appearing at the extreme right or bottom of the screen, and/or to the VTwhatever formatting codes (which I don't really understand).

Since I do a lot of editing, I find Terminal crashes several times a day... MOST annoying. So, if anyone has any idea what might be causing these crashes, or can shed any light on this stuff, please let me know!

(BTW, since Mac OS X 10.2.5, vi has stopped taking any notice of $LC_CTYPE! I'm not certain why, or what's changed, but it's easy to download the vi source from Apple's Darwin page, and recompile with a one-line fix I found to restore that functionality. I've raised a bug report with Apple about this, but - again - haven't heard anything yet.)

My two solutions: DataComet and Eterm....[+]

[ewwhite]

I run Fink and XDarwin on my Powerbook. My company produces a terminal/character-based ERP application for the produce industry. It runs on hardware terminals and also has a home-brewed PC client (with a Linux backend). We use a SCO-ANSI emulation with a few custom termdefs.

There are very few clients (puTTY and Powerterm) on the PC that can handle our product. The Mac situation is much worse. It took me a few months to find an appropriate solution for working with our clients from my Mac. The winners are:

Eterm -free- Get version 0.9 through Fink. It's much faster than Apple's terminal application and is much more configurable.
Here's a shot of a typical Eterm on my machine

DataComet -not free- but worth it. This program is similar to Powerterm on the PC side. It can handle just about any emulation you throw at it. Powerterm and DataComet both include their own font suites which allow for full PC-ANSI emulation, for example. Very comprehensive package. It integrates with the built-in shell and even handles my company's software.
Here's a screenshot of DataComet on my system

Here's a random screenshot.

Note: There is a Powerterm for Mac OSX, but it's fairly expensive, and DataComet performs as well. Hit me up if you have any questions....