Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Decent Terminal Emulation on Mac OS X?

Cliff posted more than 11 years ago | from the your-window-to-the-unix-world dept.

Software 115

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?"

Sorry! There are no comments related to the filter you selected.

How About (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6156680)

This Terminal [goatse.cx] ?

Re:How About (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6156690)

wow, that's one of the least clever goatse posts I've ever seen.

Re:How About (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6159232)

Actually, it is relevant. The submitter wanted to know if a solution was available that supported xterm mousing, and in all honesty, you could probably get a giant Gambian rat [altpet.net] in that terminal! However, I would stay away from them right now as they are spreading monkeypox.

Gnome term? (3, Interesting)

m0rph3us0 (549631) | more than 11 years ago | (#6156712)

Does Gnome term compile with the OS X version of GTK? I was thinking that might be your best route.

Re:Gnome term? (1)

Phil Ulrich (595587) | more than 11 years ago | (#6157664)

You know, it really doesn't - at least, not the fink version. I tried the other day and it died in the middle of compiling some gnome lib. I forget which, unfortunately.

Re:Gnome term? (1)

Delphiki (646425) | more than 11 years ago | (#6158123)

Is Gnome term really a good solution? While I'm all about Gnome, gnome-terminal isn't the best in my opinion. It is in my experience not especially fast and a bit of a memory hog. How about Eterm? That seems like it would be a better fit, though I don't know if it is available. Maybe when Gentoo gets ported to OS X some ports for quality terminals will become available.

Re:Gnome term? (1)

Arandir (19206) | more than 11 years ago | (#6164348)

How about Eterm?

The point of Gnome term is that you don't need X11, only GTK+ which has a native non-X11 Aqua version. With eterm you're back using X11 again.

Re:Gnome term? (2, Informative)

andfarm (534655) | more than 11 years ago | (#6158284)

It does -- in fact, the Fink project has it precompiled for you -- but it's really quite slow and suffers from the same workflow diconnectedness as xterm. Stick to xterm if you like OS X X11.

Re:Gnome term? (2, Informative)

michaelggreer (612022) | more than 11 years ago | (#6158458)

I think he meant the native Aqua gtk [sourceforge.net] . I am pretty sure nothing gnome is compiling with this yet. Also, it is only gtk 1.2.x, so no tabbed gnome terminal.

Fink (5, Informative)

qlippoth (446729) | more than 11 years ago | (#6156713)

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 [sourceforge.net]

How about... (0, Funny)

alph0ns3 (547254) | more than 11 years ago | (#6156718)

Installing Linux :D

Well, really, if a unix can't do proper terminal emulation, it shouldn't be called a unix :D

Re:How about... (1, Funny)

Anonymous Coward | more than 11 years ago | (#6157403)

bet you didn't expect that moderation, eh?

it's a new world here at /.

Moderators are on cheap crack today (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6157600)

Somehow all the goatse trolls are allowed to moderate today.

I am a Mac user and parent is +5 funny.

you could use Rxvt (4, Informative)

goombah99 (560566) | more than 11 years ago | (#6156767)

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 (5, Informative)

bobthemonkey13 (215219) | more than 11 years ago | (#6157266)

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.

Re:you could use Rxvt (0)

Anonymous Coward | more than 11 years ago | (#6157410)

screen works great on osx. never thought of using it that way. cute but a bit of kludge though just for crash protection

Re:you could use Rxvt (1)

Otter (3800) | more than 11 years ago | (#6157984)

Look into a UNIX utility called screen. I'm not sure if it's included in OS X...

It is.

Regarding the grandparent post: I use rxvt too, but the questioner's objections to xterm apply equally to its lighter-weight, prettier cousin.

Re:you could use Rxvt (3, Informative)

Mikey-San (582838) | more than 11 years ago | (#6158931)

As a matter of fact, Apple included screen in 10.2

I'd say it was an awesome move. I SSH into a box at work to attach to a screened BitchX session. Can't beat it with a stick.

Re:you could use Rxvt (1)

bedouin (248624) | more than 11 years ago | (#6164608)

I SSH into a box at work to attach to a screened BitchX session.

Or you could just use /detach from BX, and then scr-bx from your shell to resume it without loading screen.

Terminal crashes and character encoding (4, Informative)

gidds (56397) | more than 11 years ago | (#6157427)

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.)

Re:Terminal crashes and character encoding (3, Informative)

zojas (530814) | more than 11 years ago | (#6158392)

quit using vi :)

seriously, you can get vim (Vi IMproved) from fink, darwinports, or gentoo soon (console & X11 version).

even better, you can get gvim with a carbon gui at

this site [swdev.org]

I primarily use the carbon gvim now in OS X. I only use my fink version when I log in remotely to my OS X machine. Once you try vim, you will shudder at the memory of using 'vanilla' vi

Re:Terminal crashes and character encoding (1)

gidds (56397) | more than 11 years ago | (#6159443)

I tried using vim (v6.1), but I can't get that to show the Windows Latin-1 extended characters at all! (Yes, I could probably hack into it, but I really can't be bothered, not when various other things about it just annoy me - nothing major, but lots of minor differences all add up.)

Besides, the problem may well be somewhere like the curses library or the terminal driver rather than in vi itself, in which case vim would then suffer from the same problems.

Re:Terminal crashes and character encoding (1)

zojas (530814) | more than 11 years ago | (#6160053)

if the problem is curses, that wouldn't apply to gvim (X11) or gvim (carbon) since they don't run in the terminal, they have their own separate window.

also, vim has a vi compatibility mode. if one of the gui versions works with your character set, you can try 'set compatible' in your ~/.vimrc file.

I can't live without the multiple undo levels, the much more convenient cut buffer handling, the syntax-directed coloring, splitting the buffer (horizontally or vertically) to show more than one file at a time, I could go on all day.

Here's a few good screenshots of gvim in action:

carbon gvim [desertsol.com]
X11 gvim running over the net, showing a diff between two files & a vertical split [desertsol.com]

Re:Terminal crashes and character encoding (2, Informative)

gidds (56397) | more than 11 years ago | (#6160192)

True. And it does look nice. But remember that the Apple-supplied vi is really nvi, which already has multiple undo levels* and several other nice features. Buffer splitting isn't something I'd use much; whereas supporting CP1252 is a showstopper for me.

I guess what I really want is an editor with the power and flexibility of vi (navigation, REs, editing commands), but with full support for character encodings and proportional fonts. (Yes, for code too. I know, I know, I can hear the screams of "Heresy!" already. But if the code is formatted properly, I find it easier to read in a proportional font, just like English text. I'm surprised no-one else seems to find monospaced text ugly and awkward.)

(* It took me a while to work this out: you hit 'u' for the first undo, but then further 'u's just toggle redo/undo. So what you do is hit 'u' once, and then use '.' (redo) to undo further levels. Probably done that way for backwards compatibility, I guess.)

Re:Terminal crashes and character encoding (1)

zojas (530814) | more than 11 years ago | (#6160763)

that's good the shipped vi has multiple undos. how can you 'undo an undo'? (re-do)

in vim, each 'u' steps back one more undo. to redo, you hit ctrl-r. that way you can step forward and backward in the history of the document.

Re:Terminal crashes and character encoding (2, Informative)

gidds (56397) | more than 11 years ago | (#6160822)

how can you 'undo an undo'?

Use undo ('u') again! 'u' toggles between undoing and redoing, and '.' continues undoing or redoing, whatever you last did. It sort of makes sense.

Re:Terminal crashes and character encoding (1)

zojas (530814) | more than 11 years ago | (#6160925)

ok, I see. cool!

Re:Terminal crashes and character encoding (0)

Anonymous Coward | more than 11 years ago | (#6163624)

Sorry to hear about the Terminal crashing. You should send Apple feedback [apple.com] if you haven't already. And I've heard that going to the developer site, there's a way to get into their bug reporting system which may have a better chance of getting to the appropriate developer(s).

But anyway, take a look just above your post. You really want to be using screen. That way if Terminal crashes, you don't lose any of your work. Just reopen Terminal and reattach to the screen. Hope this helps.

Re:Terminal crashes and character encoding (0)

Anonymous Coward | more than 11 years ago | (#6163840)

Ah, found it in a comment below. bugreport.apple.com [apple.com] . Makes sense, too!

Re:Terminal crashes and character encoding (1)

gidds (56397) | more than 11 years ago | (#6165704)

It's already in the bug reporter!

I posted an entry there giving the locale def I wrote for CP1252, and posted the bug as a comment to it. (It didn't seem right to post it as a separate bug, as I think you only encounter it when using a locale such as my new one.)

It's difficult to see how much notice they take of the bug reporter... For the first Mac OS bug I found and fixed, an Apple techie saw a post I'd put on a mailing list about it, and mailed be about it. He was extremely helpful, and we sorted it out together. He pointed me to the bug reported, where I posted a bug about it. This was back in September last year; the fix hasn't been in the several minor releases since then; I understand it'll be in 10.3.

Then in October I posted a bug for the locale issues, and have heard absolutely nothing about it. It's still set to 'Open/Analyze', which sounds as if nothing's been done yet.

And I posted a third bug a fortnight ago, and have heard nothing on that either.

I'm not saying Apple aren't taking any notice of any of these; it'd just be nice to know whether they were or not!

And yes, in hindsight using screen should protect any other programs I'm running, though AFAICT it wouldn't stop vi from crashing regularly. And anyway, vi saves a 'recover' file, so there's rarely any permanent data loss, just masses of irritation.

Re:you could use Rxvt (1, Informative)

Anonymous Coward | more than 11 years ago | (#6162198)

Regarding Terminal crashing and loosing other Terminal windows:

You can run multiple instances of most OS X apps -- its Unix(like) after all. It's just the Finder, a totally optional application, that prevents it. From your first terminal, enter

% /Applications/Utilities/Terminal.app/Contents/MacO S/Terminal &

If you like it, soft link Terminal to /usr/local.

Eric

iTerm (3, Informative)

brianosaurus (48471) | more than 11 years ago | (#6156790)

I've been using iTerm lately. The version in CVS seems to fix some of the performance issues, though occasionally it gets screwed up and starts using as much CPU as possible. When I notice that, I start closing remote shells until it gives up the CPU. Its pretty annoying.

Unfortunately, the tabbed interface iTerm has is so compelling to me that I can't switch back to the stock Terminal.app.

I agree with the original poster about X. Running Gnome term or any other X-based terminals isn't great, since X doesn't quite integrate seamlessly with Aqua.

For now I'm sticking with iTerm and checking CVS every so often. Maybe I'll even think about looking at the code.

Re:iTerm (3, Interesting)

TomorrowPlusX (571956) | more than 11 years ago | (#6160464)

You know, when I came over to mac from linux/kde about 6 months ago, the first thing I did was install iTerm so I could have the tabbed terminal interface I had under KDE.

But, then I discovered cmd-~ will switch between windows; particularly at the time I was debugging an IPC implementation I was working on and as such needed to view two terminal outputs simultaneously -- I discovered that apple's stock terminal works great, for me at least.

Frankly, who needs tabs when you can command-tilde to switch, and command-m to minimize unneeded windows?

I would never have believed it but the mac snobs are right: tabs actually *are* a stopgap for an inadequate window management paradigm.

Learn to love cmd-~

Apple X11 xterm + pbcopy/pbpaste uber alles (0)

Anonymous Coward | more than 11 years ago | (#6156842)

title says it all

Dear Apple (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6156854)

Dear Apple,

I am a homosexual. I bought an Apple computer because of its well earned reputation for being "the" gay computer. Since I have become an Apple owner, I have been exposed to a whole new world of gay friends. It is really a pleasure to meet and compute with other homos such as myself. I plan on using my new Apple computer as a way to entice and recruit young schoolboys into the homosexual lifestyle; it would be so helpful if you could produce more software which would appeal to young boys. Thanks in advance.

with much gayness,

Father Randy "Pudge" O'Day, S.J.

rxvt (3, Informative)

eibhear (307877) | more than 11 years ago | (#6156863)

As a heavy user of cygwin on a slow desktop PC, I was delighted to see that someone had ported rxvt [rxvt.org] to that environment. It gives quite a lot of the top-class features of xterm, and little of the unnecessary bells, whistles and complete brass, woodwind and percussion sections that come with xterm.
However, for your purposes, it can also be installed and used without X11, as in the case of the cygwin environment.
What's best about rxvt is it supports what you describe as "xterm mousing". This feature alone is why I always stuck with xterm until I discovered rxvt. That rxvt has it is why I won't use any other terminal emulator for a long time into the future.

Mind you, none of this is useful if rxvt hasn't been ported to Mac OS X, but it certainly is worth checking to see if it is.

Ãibhear

PuTTY (0, Offtopic)

divbyzero (23176) | more than 11 years ago | (#6157813)

This is a bit of a departure from the original topic, but since you raised the point, I'll continue with it. If you want "xterm mousing" in a high quality, free terminal app on Windows, and you want a more native-feeling application than a cygwin port of rxvt, you might want to try PuTTY [greenend.org.uk] . PuTTY is best known for its solid SSH capabilities, but it can also be used for telnet, rlogin, and raw TCP connections. It is not a truly generic terminal, since it cannot act as a display for arbitrary local programs, but that's very rarely an issue on Windows.

Dear Father "Pudge" O'Day (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6156871)

Dear Father O'Day:

Thanks for your letter. Being Catholic myself, I know exactly what you're talking about! It has always been our plan here at Apple Computer Inc to revolutionize personal computing with our high-quality and highly gay products.

I'm happy to answer your letter by letting you know that YES we will be releasing an entire hLife ("homo-life") software line. You'll be able to recognize it in stores by the small stylized logo depicting a large cock entering a tight anus with an Apple logo on it. ("Suddenly it all comes together" indeed!).

Anyway, I hope you and other members of our community will join us on our mission, and purchase the exciting new hLife boxed set. Only the boxed set comes with translucent cock rings!

Sincerely,

Harry Rodman
Vice-president
Homosexual Liaison Services
Apple Computer, Inc.

NEXTSTEP terminal.app (4, Interesting)

macmurph (622189) | more than 11 years ago | (#6156894)

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

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

Re:NEXTSTEP terminal.app (0)

Anonymous Coward | more than 11 years ago | (#6165335)

Are they always in that weird language? ;-)

Eterm (3, Informative)

Cecil (37810) | more than 11 years ago | (#6156916)

If you're a fan of Eterm (I am), you have two options available to you:



  • Pick up an older, but pre-ported copy [forked.net] (this one is version 8.10.0)
  • Grab the CVS sources for the latest Eterm and build it yourself. This is not easy, but it is possible.


Having the latest Eterm running under Apple's X11 is nice, though I still haven't been able to get it to link with imlib2 successfully (note: I am incompetent at this stuff, YMMV) The only porting really required is to change the typedef for socklen_t to int, or include the appropriate header file (sys/socket.h?). Either works.

Good luck.

ANSI color customization (3, Interesting)

Onan (25162) | more than 11 years ago | (#6156930)

iTerm has given me the one thing that I've found seriously lacking in Terminal.app: configuration of what colors are used to display ANSI "colors". No more screaming yellow or illegible dark blue for me, thanks.

Unfortunately, iTerm does have a few limitations and bugs:

- while the xterm-experienced will like PgUp/PgDown going straight through, and using shift for local scrolling, I'd really like to see this togglable.

- no Home/End functionality, with our without shift.

- no local Find.

- it "helpfully" doesn't include whitespace when copying out of its windows. Actually, I did want that linefeed, thanks.

- periodically decides it wants to just sit and suck all my cpu until I kill it.

- font settings don't stick between launches.

I've also found that Terminal.app's split-window function is surprisingly useful. And unique, in my experience.

Re:ANSI color customization (1)

gklinger (571901) | more than 11 years ago | (#6157106)

Terminal.app's split-window function? I've never seen that function in Terminal. Could you elaborate.

Re:ANSI color customization (3, Informative)

megabulk3000 (305530) | more than 11 years ago | (#6157300)

click the little widget on the right hand side, just above the scrollbar and below the title bar, and voila.

Re:ANSI color customization (1)

gklinger (571901) | more than 11 years ago | (#6158585)

Ah. I operate without a scrollback buffer so I don't get the scrollbar ergo I don't get the little widget. I just tried it and it split the screen but the behaviour was very odd. It doesn't appear to be two seperate terminal windows but a way to view things that have already scrolled off the screen. Strange. At any rate, Terminal.app still isn't the greatest but for now, it's the one I like most. I just wish Apple would improve the speed and add some tabs. That would be just great.

the split widget thingy (1)

Onan (25162) | more than 11 years ago | (#6158662)

Yeah, that function of Terminal is odd, and hard to give a description or name, but surprisingly handy. It allows you to simultaneously see and interact with two arbitrary segments of scrollback within a single window.

This facilitates doing a variant on a long series of steps you did a while earlier, comparing previous output of an operation to current output, or just reading deep scrollback without missing new data. It's not a life-changing feature, but it is regularly useful.

Re:ANSI color customization (1)

entrox (266621) | more than 11 years ago | (#6159815)

You don't really need tabs: there's a nice keybinding for switching between terminals. Try cmd-left and cmd-right to go the previous/next terminal window. I was delighted when I found that one out :)

Re:ANSI color customization (1)

TomorrowPlusX (571956) | more than 11 years ago | (#6160504)

Or command-~, like *all* mac os x apps, it will switch between windows.

Why have a differnet keybinding for the same logical action?

Re:ANSI color customization (1)

gklinger (571901) | more than 11 years ago | (#6161693)

I use an iBook so screen real estate and memory are at a premium. I would prfer to have a single window with tabs rather than multiple windows. I had never seen tabs in action until Apple added them to Safari and now I can't live without them. What I like best is that you can see what's open in each tab without having to look to the Window menu. Screen is great but I'm often connected to multiple systems with screen running remotely and I hate having to use nested ctrl-a a sequences. As long as I'm babbling away like we're in comp.sys.mac.misc, I would love to have a full-screen mode. Not being able to go full-screen with a terminal is just wrong, Sure, you can login to the console but then you can't start up Aqua (or X for that matter, which is silly). Let's just hope that Apple doesn't consider Terminal to be finished.

Re:ANSI color customization (0)

Anonymous Coward | more than 11 years ago | (#6163688)

Just use screen. Ctrl-A Ctrl-A, no mousing required, baby! :)

PuTTY (4, Informative)

zsazsa (141679) | more than 11 years ago | (#6157073)

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

(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 [debian.org] ).

Re:PuTTY (1)

dre80 (613210) | more than 11 years ago | (#6159924)

That would be sweeeeeet!!

Seriously, that's about the best news I've read today. I love PuTTY under Windows, can't wait for the Mac version! According to the Mac Port Readme [tartarus.org] , the project is moving along smoothly and there are builds for MacOS X and for earlier versions (System 7 and up), both for PPC and 68k.

I think this one will be our answer once it's completed, I have high hopes!

Konsole (1)

JabberWokky (19442) | more than 11 years ago | (#6157084)

Fink has ported KDE, so if you like Konsole (I do), then it's available. Of course, you need the whole KDE compiled plus X11, but you just need X and Konsole running (plus DCOP, but that's the overhead for all KDE apps, since that's how they share objects).

--
Evan

Java Options (2, Informative)

kwerle (39371) | more than 11 years ago | (#6157165)

I've been happy with Apple's Terminal.app since 10.2 (export TERM=xterm-color :-)

I know that there are a few Java terminal emulators (check sf.net). I alwyas liked mindterm for ssh connectivity. I know they closed source, but there's a fork out there somewhere from the last open version.

Anyway, could you post a followup to your article when you settle on something - just a comment would be nice.

I wonder if the editors would let you update the article...

TERM environment variable make a difference (5, Interesting)

payam (43863) | more than 11 years ago | (#6157259)

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.

Re:TERM environment variable make a difference (2, Informative)

nosferatu-man (13652) | more than 11 years ago | (#6158661)

Terminal.app also emulates DEC's tres-cool dtterm. Just set your TERM variable to dtterm. It's a superset of xterm-color functionality, as near as I can tell. As it happens, you can make Terminal.app do all kinds of wacky things with escapes. For instance:

alias dock='echo -n "[2t"'
alias lower='echo -n "[6t"'
alias raise 'echo -n "[5t"'

Here're [mac.com] some more.

'jfb

Re:TERM environment variable make a difference (2, Informative)

Anarchitect (9282) | more than 11 years ago | (#6159420)

dont forget 'Apple_Terminal'
  • /usr/share/terminfo/41/Apple_Terminal
works great. Arrows and _PROPER_ vim syntax coloring.

And if you were to use teh One True Edit0r [vim.org]
:colorscheme elflord r0kkz tha HiZZ0uSE!

sorry about that. It just sorta came out.

MacSSH (2, Informative)

gozar (39392) | more than 11 years ago | (#6157623)

I went looking, and the only one that would do decent vt100 emulation was the OS 9 app MacSSH [wanadoo.fr] .

We need it to access a VMS machine, and no other term emulators would work as flawlessly as MacSSH. I would LOVE to be proven wrong, if someone can point me to a term app that allows me to use the function keys and the keypad correctly!

Re:MacSSH (0)

Anonymous Coward | more than 11 years ago | (#6159077)

Decent, before it crashes whenever data comes in at anything approaching half line speed. Stability seems to increase with the number of hops between you and the host.

Re:MacSSH (1)

macdaddy (38372) | more than 11 years ago | (#6163406)

I was never a fan of MacSSH. I used NiftyTelnet w/ SSH [versiontracker.com] back when I used OS 9. It was more simple than MacSSH but worked so much better. When I switched to OS X I ended up using JellyFiSSH [versiontracker.com] to organize my Terminal.app connections. Terminal.app would crash on me once a day or so as well. The damned thing never did quite work right. I don't have an OS X box available anymore, unfortunately. Otherwise I'd be more in touch with this problem. I'm holding out for a SMP G5. :)

That said I have yet to find any terminal emulator on any platform (Mac, Windows, even *terms in X11) that I couldn't make crash at some point. Even SecureCRT which I have to use here at home has crashed on me before.

Re:MacSSH (1)

Killer Eye (3711) | more than 11 years ago | (#6165594)

MacTelnet [mactelnet.com] , despite its name, can run local Unix apps on Mac OS X. It shares much of the same base code as MacSSH so it still has VT100, VT220 and TEK. However it also supports VT52 mode, double-sized text and most XTerm sequences, and has VT220-specific features like floating keypad windows. I should know, because I am writing its (open-source) code! :)

GNUStep? (2, Interesting)

ActiveSX (301342) | more than 11 years ago | (#6157983)

Perhaps you could hack the GNUStep [gnustep.org] Terminal.app to compile with Cocoa. For those who don't know, GNUStep is a GPL'd implementation of the OpenStep Specification of yore.

Re:GNUStep? (0)

Anonymous Coward | more than 11 years ago | (#6159013)

Nope - it isn't that easy. GNUStep's Terminal.app does use several GNUStep only features. IMO it would be easier to rewrite a Term from scratch than porting Terminal.app.

Serial Terminal (0)

Anonymous Coward | more than 11 years ago | (#6157999)

I have used ZTerm on Mac OS 9 for a long time to comunicate with a Micro Processor via the Serial Port. I have tried ZTerm for Mac OS X and it is unable to correctly send text files through at full speed.

I was wondering what Serial Terminals for Mac OS X or for Linux people would recommend.

color xterm emulation is easy in Terminal.app (1)

zojas (530814) | more than 11 years ago | (#6158352)

To get Terminal.app to do decent color xterm emulation:

setenv TERM xterm-color

I didn't have to fiddle with stty either.

Re:color xterm emulation is easy in Terminal.app (2, Interesting)

nosferatu-man (13652) | more than 11 years ago | (#6158672)

You're better off with TERM set to dtterm, if'n your application supports it. Just in case you thought progress in computing had been made in the last 25 years, along comes a happy reminder like terminal handling to show you the error of your ways.

*scowl*

'jfb

Re:color xterm emulation is easy in Terminal.app (1)

zojas (530814) | more than 11 years ago | (#6160073)

I'll give 'dtterm' a try. what did that improve for you? thanks

My two solutions: DataComet and Eterm....[+] (5, Informative)

ewwhite (533880) | more than 11 years ago | (#6158795)

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 [greenend.org.uk] and Powerterm [ericom.com] ) 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 [eterm.org] -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 [djedwhite.com]

DataComet [databeast.com] -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 [djedwhite.com]

Here's a random screenshot [djedwhite.com] .

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....

Point Drawoc to Google? (1, Informative)

Anonymous Coward | more than 11 years ago | (#6158887)

Looks like Drawoc needs to use Google a bit more after reading all the comments.

Actually XDarwin isn't that bad (I run it) and I'm also running (just playing with it) the Apple beta for X11. XDarwin provides a host of opportunities for Term apps and what's this "doesn't fit in the workflow very well" jazz all about? Has he tried it? Not from the sound of it.

Lots of good ideas but I thought I'd stand up for XDarwin. Quite frankly I don't use it much but do run X11 sometimes alongside OSX and OS9, all concurrently.

Personally I use Apple's weak kneed Term app and find it adequate. It sounds to me like ole Drawoc is nitpicking some stuff many (including heavy users) could care less about. Maybe he's wedded to PC habits. The OSX Term app offers some nifty features of its own although Mac interface is obviously limited.

But as long as I can cut/copy/paste to/from it and handle by Griffin Power Mate to scroll it *quickly* (you can program this thing to grill hotdogs I suspect) then maneuvering around is no biggy and I sort of like having four or five Term app windows open and handy in my second monitor.... no CPU usage to speak of and with two G4 1.25 GHz CPUs I'm not used to seeing beach balls when in terminal mode. ;) LOL

Same Problem (0)

Anonymous Coward | more than 11 years ago | (#6159008)

I had the same problem on my iBook. After several months of trying to find an usable terminal i decided to dump OS X and install linux.

Re:Same Problem (0)

Anonymous Coward | more than 11 years ago | (#6159015)

really?
This is so lame. It is like one would buy a porsche and put some toyota engine inside..... lol

PageUp/PageDown (1)

Tsk (2863) | more than 11 years ago | (#6159143)

"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"
Please take a minute and open a bug at bugreport.apple.com.

Have you tried (3, Informative)

Tsk (2863) | more than 11 years ago | (#6159167)

Re:Have you tried (1)

macdaddy (38372) | more than 11 years ago | (#6163446)

I want to give a plug to these folks. I've never used their terminal emulation software. In fact I haven't used their software in about 5 years. The last product of their's I used was VICOM Internet Gateway (now called Intergate apparently). I loved their software back then and still do. Their support was also first rate. If the quality of their work and service is still as good, then you should have no problems with their terminal emulation solutions. My $.02

Re:Have you tried (0)

Anonymous Coward | more than 11 years ago | (#6165053)

the problem is lack of OS-X terminal apps... the first here is a classic app. who is stupid enough to have classic installed?

Cursory look through discussion (-1, Redundant)

Knife_Edge (582068) | more than 11 years ago | (#6159178)

Nobody has mentioned GLTerm. This program does not look as nice as Terminal.app (especially if you like the transparency feature, which it does not have), but it is much faster. Much faster. It renders the entire contents of your terminal using OpenGL, bypassing Quartz entirely. I used it frequently on my old iBook (no Quartz Extreme support was possible on this machine, and the Terminal.app really lagged). It really fits the bill if you are frustrated with Terminal.app's slowness.

More information is available here [pollet.net] .

Re:Cursory look through discussion (1)

Knife_Edge (582068) | more than 11 years ago | (#6159185)

Oh great, GLTerm was not in the discussion because it was in the article. I guess I should be prepared for more Ask Slashdot's where the author asks a question, and then proceeds to answer it themselves. Whoops.

IBM 3270 terminal (1)

Erik K. Veland (574016) | more than 11 years ago | (#6159302)

If you need to connect to a IBM 3270 (and similar mainframes I guess), there's a very nice free client [macupdate.com] that's running just fine in Mac OS X.

What makes the Terminal.app really nice to use... (0, Redundant)

snowtigger (204757) | more than 11 years ago | (#6159347)

... is to have a nice complete file. It specifies what shows up when you type [tab].

The basic configuration of tcsh (or your favorite shell) is not very userfriendly in Mac OSX (it only completes when there are no ambiguties). It's soo nice to have an inteligent shell that does half the work for you.

A nice example is when programming, typing "make [tab]" makes the shell search all the possible choices in the Makefile and complete.

I took the /etc/SuSEConfig/complete.tcsh file from my SuSE Linux box, it worked straight away.

Re:What makes the Terminal.app really nice to use. (1)

macdaddy (38372) | more than 11 years ago | (#6163504)

To hell with tc shell. tcsh has always annoyed the living hell out of me. Get a real shell like Bash [freshmeat.net] . Tab completion in bash is excellent. Even better, look into the Bash Programmable Completion Project [freshmeat.net] . It's quite nice. Skip the csh, tcsh, and kornhole shells. Stick with what works well: bash.

The *Best* terminal I've found.. (1, Informative)

KrON (2656) | more than 11 years ago | (#6159498)

Is GLTerm [pollet.net] it is opengl accelerated (woopee), and has support for some popular linux fonts, including ones that actually contain high ascii chars so you can irc in beautiful color.. it's shareware though, but the guy who writes it is really cool, so I shelled out the $20

Re:The *Best* terminal I've found.. (-1)

KrON (2656) | more than 11 years ago | (#6159505)

Correction, it was only $10 :)

Re:The *Best* terminal I've found.. (0)

positive (12069) | more than 11 years ago | (#6161418)

The only gripe I have with GLterm is that the windows appear blank when minimized to the dock due to the way they're rendered.

Re:The *Best* terminal I've found.. (-1)

KrON (2656) | more than 11 years ago | (#6161550)

I have 2 gripes:

1) If you are on a laptop using energy saver stuff, and your screen falls asleep, and you wake it up, the terminal is screwed till you click on it or ctrl-l

2) When resizing windows, if your height or width of the window isn't divisible by 8 or 12 (i forget), it blurs the hell out of your text (due to opengl font smoothing). Not a big deal, you can always resize it a bit bigger or smaller and it will be ok

xterm (1)

coaxial (28297) | more than 11 years ago | (#6159548)

The G4 I messed with at the Apple Store had X11 and xterm installed. Just use xterm dude.

Python in Terminal.app (1)

kyrre (197103) | more than 11 years ago | (#6159602)

Has anyone gotten the arrowkeys to work using python in Terminal.app? All I get is: ^[[A^[[C^[[B^[[D

It is so much easier to prototype code in Python when the arrowkeys are working. I've tried bash and tcsh.

Re:Python in Terminal.app (1)

Fished (574624) | more than 11 years ago | (#6160462)

This is more likely an issue with your python build. You might try rebuilding python. (Or, better, just use Ruby instead. :)

Re:Python in Terminal.app (1)

kyrre (197103) | more than 11 years ago | (#6161446)

Its the one that comes with os x (Developer Tools). But I could try that of course. As for Ruby: No.

Re:Python in Terminal.app (0)

Anonymous Coward | more than 11 years ago | (#6165019)

The problem is that the stock Python does not have readline compiled in. That's because readline is GPL'd.

Anyway, you can get readline to work with the stock OS-X python. do a google search, or search the archives of the macpython mailing list. It's easy once you know how. And yes, you really do need it to be productive with Python.

Re:Python in Terminal.app (1)

kyrre (197103) | more than 11 years ago | (#6165488)

Thank you kind sir.

Re:Python in Terminal.app (0)

Anonymous Coward | more than 11 years ago | (#6165413)

It's an issue with the Python that's distributed with the developer tools; they haven't enabled readline support due to GPL issues.

However, there is a module that you can use to get readline and Python working:

http://www.versiontracker.com/dyn/moreinfo/mac/1 63 48

WRQ's Reflection Products is the Answer. (1)

Dolemite_the_Wiz (618862) | more than 11 years ago | (#6159636)

WRQ is the industry leader in Solid Terminal/X/RDP emulations for many years. Their products have been getting better and better over said years.

Check it out. [wrq.com]

Dolemite
_________________________

this might work (1)

NeXT_lives (680242) | more than 11 years ago | (#6159637)

if you don't need a lot of bells & whisles try NCSA Telnet, still a work in progress. http://www.mactelnet.com/

vttest - VT100 (and more) test suite (2, Informative)

Creosote (33182) | more than 11 years ago | (#6160223)

Sorry to be late with this, but anyone interested in evaluating terminal emulator programs should know about the classic "vttest" program, as updated by Thomas Dickey [freshmeat.net] . It compiles under OS X without any tweaking.

Of the programs mentioned in this thread that I've looked at, there's not a one that passes all the relevant tests. And Terminal.app does better than most at some of them, like the character set test and Xterm window-modify features.

My favorite terminal emulation program, PC-compatible only alas, is VanDyke's SecureCRT [vandyke.com] , which does well on vttest and comes with a nice terminal font set. (Luckily I'm at a school with a site license; regular individual price is $99.)

export TERM=ansi (2, Informative)

exp(pi*sqrt(163)) (613870) | more than 11 years ago | (#6160342)

Full screen vim with PgUp/PgDn now work fine for me.

Re:export TERM=ansi (1)

Creosote (33182) | more than 11 years ago | (#6164061)

Full screen vim with PgUp/PgDn now work fine for me.
? ? ?

Doesn't work for me. PgUp/PgDn in Terminal.app still sends the keystroke to the Scrollback function. What exactly are you doing to achieve the desired result?

Re:export TERM=ansi (1)

exp(pi*sqrt(163)) (613870) | more than 11 years ago | (#6164971)

I'll check when I get home tonight. There is a fix as it works 100% perfectly for me - I definitely don't get scrollback and I'm using Terminal.app.

Default Terminal window location.. (1)

Delta-9 (19355) | more than 11 years ago | (#6163920)

This has driven me crazy for some time now. Is there anyway to get the default jaguar terminal app to save its last window location?

dataComet (1)

Gryphon (28880) | more than 11 years ago | (#6164370)

The only fully VT420 compatible terminal client for OS X that I've found (that works perfectly with DEC TPU and similar VMS applications) is dataComet (and dataComet Secure, which provides SSH support). See http://www.databeast.com/ .

It doesn't behave quite the way an OS X program should (the Preferences window is non-standard, for example) but the emulation is excellent.

YMMV.

MacTelnet For Local Unix, TEK, VT100/VT220/XTerm (1)

Killer Eye (3711) | more than 11 years ago | (#6165617)

MacTelnet [mactelnet.com] , despite its name, can run local Unix apps on Mac OS X. It shares much of the same base code as old favorites like MacSSH, so it still has VT100, VT220 and TEK. However it also supports VT52 mode, double-sized text and most XTerm sequences, and has VT220-specific features like floating keypad windows.

I should know, because I am writing its (open-source) code! :)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?