So, I have this bash script that runs AppleScript that I use to start up a bunch of servers at once, each in their own Terminal tab. At the heart of it is this 'new-tab' function[1]. I don't really like AppleScript, and would like to not use it.
Can I duplicate this functionality using iTerm, without using AppleScript?
Yes it's technically interesting but am I alone in thinking that it sort of defeats the purpose of using tmux in the first place?
I use tmux partly because I come from a background of low resources, but also because I want my essential tools to use as little resources as possible so that they always work as well as possible on any system.
Yet iTerm proposes that you use their GUI tabs, split their GUI terminals instead of drawing it all with tmux in one text console.
I guess you sacrifice some resources for usability.
If your main purpose for using tmux is sparing resources, then sure, but I think most people use tmux for session management, persistence and multiplexing. If I can use these features in a way that is better integrated with the windowing system, and still be able to attach to the session from a plain terminal remotely, I'm not going to complain.
Does tmux integrate with itself? That is, does this solve the problem of needing different prefix keys when nesting tmux sessions (whether using iTerm2, or using a terminal emulator that doesn't itself integrate with tmux)?
I thought that, when nesting tmux instances, you just press the prefix key a number of times depending on how deep you need you need your next keystroke to propagate?
For me personally, I use ctrl-a instead of ctrl-b so I have this line in my ~/.tmux.conf:
#send prefix to nested sessions with C-a
bind-key C-a send-prefix
Lastly, iterm2 uses it's own keystrokes for it's tmux integration. (i.e.: cmd-D to split vertically)
I have tmux set up so that pressing the prefix key twice switches to the previously selected window. I don't remember whether it was like that out of the box, or whether I had to configure that when I switched from gnu screen.
I take it with nested tmux sessions, cmd-D would split the outer tmux window? How would you split the inner tmux window?
> I don't remember whether it was like that out of the box, or whether I had to configure that when I switched from gnu screen.
It's worth checking your config file out.
And I'm not sure how to answer your question because the way iterm integrates with tmux is that it allows you to create split panes with their own bash sessions. If you want to run tmux in those sessions, it would be tmux running in that pane, but textually instead of graphically. Here's a screenshot to make things more clear: http://i.imgur.com/0hmw62I.png
The issue I've always had with the tmux integration is that it doesn't support multiple sessions simultaneously. I am typically moshed into several hosts and running tmux on each of them. I'd love to have one window per session with tabs corresponding to tmux windows.
I'm a little surprised more people don't run into this more often. I've never seen the benefit in running tmux locally. Do most people only ever use tmux on one remote host?
Edit: it's been a while since I've tried it; apparently tmux integration doesn't work over mosh at all. So s/mosh/ssh/g above and it still applies.
FWIW, I've tried switching to iTerm about 3 times and I've always to come back to Terminal.app because it feels more
"solid or "native" and it minimizes the installation + configuration I need to do on a new machine to feel comfortable.
Likewise - I live in Terminal.app all day long, 4-6 hours at least, and for some reason I always return back to Terminal.app - particularly now that I can auto-rename tabs when I ssh into other other hosts (PROMPT_COMMAND='printf "\033]0;remote_host\007"').
With that said, I'm going to give iTerm another try - the tmux support is intriguing...
One of the nice (newish) features if iTerm2 is the ability to store your config in Dropbox (or other arbitrary location). This means that all the machines I use have an identical configuration.
Well, I started working at a place where I was regularly juggling 2-4 SSH sessions, 2 programs running and dumping logs in other tabs, plus a few more open terminals, and after a coworker introduced me to the wonderful zsh[1], I wondered what other great tools I was missing. That's what led me to iTerm2.
I stuck with iTerm because of the many, many little features and conveniences that make working with the terminal easier.
Tabs can be put at the bottom of the screen, which solves that pesky issue where changing tabs on a fullscreened terminal.app causes the OSX topbar to slide down and intercept your click. Tab titles change color depending on the kind of activity that's going on within. Hotkey mapping is a lot more powerful, and lets you send arbitrary hex/escape codes with hotkeys. There's a drop-down mode, like Tilda or Visor. This might just be placebo, but I'm pretty sure it also glitches out less often than Terminal.app.
All in all, everything is just a little bit nicer than the stock terminal.
I found that iTerm provides a slightly better experience with Vim: colorschemes were rendered more accurately and redraw performance was improved (most noticeable when scrolling the window line-by-line with CTRL-E and CTRL-Y).
However, MacVim improves again on those two points, so I end up using that.
I second this. I'm using Terminal.app for years now, dabbled with iTerm from time to time, but just couldn't see any advantage; since Terminal.app allows me to save window layouts and customize colors - so far, it's all I need from my Terminal emulator. The rest is the shell's job.
Mouse reporting. You can scroll text with mouse wheel, you can click on text and move the cursor there, so you can have say vim essentially behave like graphical vim (silly example I know, but still it's useful to some people). You can resize vim split windows with a mouse.
iTerm exports its color profile as shell variable, so you can have vim adjust its color theme to match the terminal theme.
It has better full screen support.
It has support for foreground/background color of the text the cursor is over, which Terminal.app does not have at all. This is why in vim if you cursor is over syntax highlighted element whose color is similar to the cursor color, it become incredibly hard to tell where the cursor is (esp. on large screen).
iTerm has "highlight cursor feature", to quickly show you where the cursor is (CMD+/). This is useful if you went away from the screen for a while and you come back, and can't immediately spot the cursor.
iTerm has better font rendering (more like GUI Vim) because it is a Cocoa view.
iTerm allows you to split terminal windows both horizontally and vertically.
The list goes on, but these are some highlights. Essentially, you have more control over your terminal.
I switched because of the Yakuake/Guake/Quake 3 console like functionality it has. I don't live in the terminal but need it constantly, hitting <C-`> is easier than ⌘-Tab-ing until I find the right window.
> I switched because of the Yakuake/Guake/Quake 3 console like functionality it has.
I made the switch from Terminal.app myself when iTerm finally added the feature, but Terminal.app had this functionality available via a SIMBL plugin (oh man, remember those?) called "Visor" for several years, but it was always a hack that would stop working for a few weeks/months whenever a new version of OS X was released.
It looks like Visor has now been replaced with TotalTerminal, another hack in the form of a wrapper application bundle: http://totalterminal.binaryage.com/
I switched to iTerm.app at the same time I switched to Vim only because Terminal.app didn't support 256 colors at the time. Although Terminal.app now supports 256 colors (it's been 3 years) I got used to iTerm.app and just keep using it out of habit.
Small things like a sane full screen shortcut and easily turning off those godawful window animations that make you feel like your mind has been trapped in someone else's powerpoint presentation.
I use Terminal almost exclusively in full-screen mode, and iTerm allows me to do just that.
And no, Terminal.app does not have full-screen mode that is useful. Lion-style fullscreen apps are absolutely useless to me, since you can't bind them to ctrl-[1-9] hotkeys to switch between spaces.
I might have a workaround for you! I use a launcher for OS X called 'Quicksilver'. It's free and absolutely changed the way I approach computing (at the speed of thought, not the speed I can aim and click icons on my screen) and one of the handiest features Quicksilver let's you configure is called 'triggers'. Triggers are system-wide shortcuts that run a quicksilver command. So I have a quicksilver trigger for EVERY application I use.
Any time I hit my special trigger key combination, it will 'launch' that app. If it is open it gives it focus, and if it is not running it opens the app. This means I can rearrange my apps and desktops however I like and I always instantly travel to the app I want next.
Terminal is command-shift-I anywhere. Chrome is command-shift-c for example. Firefox is command-shift-f. Let's say I'm editing an HTML file over ssh and I want to test it. It doesn't matter whether chrome or Firefox are running, full screen, on the same virtual desktop, if I strike command-shift-c Chrome is instantly in front of me. I flip between programs all day and don't use my dock except to empty trash (and yes I know command-option-shift-delete but that is living on the edge!)
Yes! This is almost exactly what I do, except s/command/control/, and I'm using Alfred instead of Quicksilver.
Not sure if Quicksilver has this, but one nice feature is that if, say, Chrome is currently active, and I hit its key-combo (control-shift-c), Chrome is hidden (the equivalent of command-h). This is great if you're installing something in the background and want to see if it finished without reverting back to the dark ages of command-tab.
It's especially nice on a laptop, because I can expand all my windows to fill the screen while still having near-zero overhead when switching between apps.
I do the same with spaces and Divvy. I have 8 spaces.
Space 1 is full screen browser.
Space 2 is full screen terminal.
Space 3 is full screen music app.
Space 4 is full screen mail.
Space 5 is full screen code editor.
Space 6 is IM/Twitter.
Spaces 7-10 are used as needed.
It works just fine, I know where every app is, so I just go directly to that space with ctrl-$SPACENUMBER
Now, note that I say full-screen, I mean "with menu bar visible, maximized using Divvy." I can't use system-provided full-screen API, because I lose ability to use only keyboard to navigate around.
> Any time I hit my special trigger key combination, it will 'launch' that app. If it is open it gives it focus, and if it is not running it opens the app. This means I can rearrange my apps and desktops however I like and I always instantly travel to the app I want next.
What if I have 6 full-screen Terminal windows (connected to SSH servers, tmux sessions, and so on), and I need to switch between them? Your comment prompted me to install Quicksilver, but it doesn't seem like it can handle that. I'd be glad to hear if I'm wrong.
The built-in tmux session stuff is fabulous. Makes me never want to use normal tmux again.
I also quite like that iTerm allows non-Lion full screen mode. That combined with some tasteful transparency lets me see stuff happening while I'm poking around at the command line. It's nice to visually see the result of a Control-C or the relaunching of a web server.
> Deep tmux integration. iTerm2 can speak directly to tmux and display its virtual windows as native windows or tabs, making tmux much easier to navigate.
I actually prefer Terminal.app otherwise, but the tmux integration is so good it's worth it just for that.
- Good fullscreen support. Normal terminal can only go into "Lion fullscreen" which means it will be on a separate workspace and you can't have other windows besides it.
- Configurable keyboard shortcuts
This has always kept me coming back to iTerm. (The configurable word separators is handy too. Obviously the people that work on Terminal.app don't have many files with hyphens in them, but I seem to have loads.)
* search starts from the bottom of the buffer (most recent result).
* I can cmd+click filenames with line number (in error messages) and have them open in my text editor with cursor on the right line.
* notifications when background tab becomes idle - notifies about finished long-running builds/installations, etc.
* much better, customizable keyboard shortcuts. Supports meta keys properly. I have keyboard shortcuts for opening a tabs connected to my servers, disabled annoying "Print" shortcut, etc.
* 256-color support. This was added in Lion I believe.
* There's a really weird bug with word-wrapping that only manifests itself in Terminal.app: http://superuser.com/q/46948/5966 As of 10.9, I believe it remains unfixed.
Smarter "dobule-click to select" logic. iTerm seems to highlight exactly what I want when I double-click in the area. Last I tried Terminal, it missed the mark.
Select to copy. I know some people can't understand why anyone would want this, but I've become accustomed to it. One thing that does still annoy me, even with iTerm, is that I find after I select something I need to move my mouse for it to copy.
I imagine 256 color support was a deal breaker before Lion, but I'm still an iTerm guy because of those reasons above.
Yes, select to copy a thousand times. If you're used to xterm, this is invaluable, especially if you're then just pasting the selection into another terminal with middle click. It saves many mouse/keyboard transitions.
I use it exclusively for the visor mode. Which I have set up to be like full screen mode on a laptop, but is limited to half the screen when I plug into an external monitor. It's also bound to show/hide on ctrl+`.
Unlike most others it seems, I don't utilize the tmux integration, despite using tmux heavily.
There is a bug in terminal.app that manifests itself when you ssh to remote servers, launch something like tmux, disconnect, and try to resize the window[0]. The bad part for me is that this happens every time I leave my desk (the terminal resizes to the laptop screen size, and my usb ethernet dongle gets disconnected).
It was a very basic thing that caused me to switch: Being able to use Cmd-1, Cmd-2, Cmd-3, etc to switch tabs (Terminal.app only does this for windows, not tabs).
What converted me to iTerm was using Vim with a decent color scheme (e.g. Solarized or Base16). Even though supposedly it's possible in Terminal.App, I could not get it working (Mavericks). After hours upon hours of trying, and retrying, I gave up (in?) to iTerm because it just worked.
I do prefer Terminal.App. To me it feels more polished and stable and I'm used to it and it comes with the OS. I appreciate iTerm and the work put into though and it's what I currently use, but if I could get my Vim setup working in Terminal.App I would switch back.
Similar experience. I could never get Vim color schemes to work properly in Mavericks, despite many attempts.
I've been using Terminal on Yosemite, and for what it's worth, the Solarized theme works properly. I'd forgotten how much trouble it was in the past.
My current setup is to run tmux inside Terminal, with the 'Option as Meta key' flag enabled. Then configuring tmux to use Option-A (instead of Control-B) preserves the standard emacs shortcuts. So Control-A and Control-B still work to move to the beginning of the line and back a character. Mapping Control to Cap Locks, and using Option-A for tmux has served me well so far.
I agree that Terminal seems more polished (start up time and ability to keep up with typing speed - iTerm seemed slightly laggy compared to Terminal). But I'll give iTerm another try - the configuration options are impressive.
First, thanks for releasing this! Second, silly question, but what is the recommended way to navigate long commands? Is there a way to click my cursor to a specific point, or a keyboard shortcut to navigate large blocks of words? I tried OPTION+LEFT-CLICK, but sometimes it will have the effect of moving my history to the current command.
Besides Firefox, iTerm2 is my most used app, by far. I love the customizability of it, the Visor mode, and how stable it it to work with. I've used it so long, I don't even remember why I don't use Terminal.app any more.
I like the idea of triggers.
auto-highlighting the following regex's makes life a bit better whille reading logs and traces.
.[eE](rror|xception). highlight error lines
:\d+ highlight line numbers in ruby (captures bits of time stamps though...)
[lL]ine \d highlight line numbers in python
I bet there are more creative uses. please enlighten me.
Dang, looks like there/s still no preference to disable creating a new window when iTerm launches or is clicked on in the Dock. I only ever use iTerm via system-wide hotkey (i.e. Quake-style HUD mode), and it's kind of annoying that it automatically creates a duplicate window whenever it launches that can't be hidden via the hotkey.
It doesn't do that for me. Whenever I click on the dock icon or fire it up via spotlight, iTerm goes in the foreground, but there is no duplicate windows created.
You need to create a saved window arrangement (Window -> Save arrangement) with no windows open, then set this as the default arrangement in Preferences -> Arrangements, and finally change the Startup preference to "Open default window arrangement" (on the General tab).
Wow, this is great: it still creates a new window when clicking on the dock, but it no longer creates one on startup. That's still a lot better than before. Thanks!
Ah, I work with iTerm hidden from the dock and purely in "Visor" mode. If I actually want a regular window to keep around, I can create one by bringing up the visor and then hitting Cmd+N.
One feature I really wish iTerm2 2.0 would have introduced was better session restoration support. With Terminal.app, you can issue a command like 'ls' and then quit and re-open Terminal.app and the previous output from 'ls' shows up. This is incredibly useful when you have to restart or if your system crashes and you have some output that you wanted to preserve.
I see from the changelog that some type of restoration has been included: "Support for OS 10.7 features including fullscreen, retina graphics, and window restoration"... but upon actually trying it out, it doesn't do what Terminal.app does.
The history is a property of the shell (bash, zsh), not the terminal.
Edit: I wrote a thing here about the difficulty of carrying history across terminal sessions and how can you associate a tab you open now with a tab you had open in a previous session, but then I realised that I misread your post.
I would expect the answer in the posted link to work. The 'share_history' option, when set, tells zsh to reread the history file before performing history lookups.
Maybe try the set-local-history option documented here?
tmux doesn't help you in this scenario, because the tmux process is lost during a system reboot. I concur with the parent - Terminal.App's ability to restore the previous sessions output after a system crash (which on my macbook Air ranges from daily to weekly - FTDI USB Drivers and Display Port cable being to the two major reason) really make me appreciate that feature.
"FTDI USB Drivers", if it's the VCP ones the very latest ones have been reasonably stable for me. I've not had a system crash for quite a while now, whereas I was having them weekly with an older version.
Nope - I'm on the latest 2.2.18 drivers still flakey as can be - This has been an ongoing issue for me for about two years - it's a pain when you are working on a Cisco Router, and you unplug the cable and kernel panic. I guess on the (weirdly?) pro side, it's at least fairly consistent - about 20% of the time, the Macbook (two generations now for me, 2010, and 2013) kernel panics.
This is where Terminal.app (or possibly OS X 10.9 + Terminal.app) ability to show you your terminal history on recovery from Kernel Panic is really appreciated.
If only there was a reliable USB-Serial cable/controller/interface for the Mac. Unfortunately, RS-232 is so rare (except for consoling into Cisco Routers?) that there is no incentive for any vendor to actually write a half stable driver.
I don't know what sort of serial adapter you're using, but I've used a number of the PL2303-based ones over the years (currently a Trendnet TU-S9), and have never had them cause any sort of instability. Weird.
I've never found any one particular USB-Serial Adapter to be any more reliable with the FTDI drivers on the Mac. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
I've never found any one particular USB-Serial Adapter to be any more reliable. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD. Still kernel panics when I pull out the USB Cable.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
I assume it pertains to Lion-style window restoration. Before 10.7, when you restarted your computer, you had to open each and every app (and every window!) again.
Since 10.7, system (assuming the app cooperates, that is) does that for you and reopens everything.
I agree with your sentiment and it is depressing to see you downvoted. On HN I would have hoped your comment would stimulate those familiar with the code base to offer hints of where to start hacking, rather than rapid down arrow clicks.
He was downvoted for the dismissive and condescending attitude, which helps no one. The idea that anyone can work on iTerm is fantastic, but when someone posts a suggestion/request/wishlist item and is essentially told to 'do it yourself' that just comes across as hostile and unwelcoming.
The exact same sentiment could have easily been posted in a friendly and welcoming manner, but that didn't happen and that's why he's getting downvoted.
> Wow, being downvoted for suggesting to hack something yourself on Hacker News ... that's a new one. I guess I'll take a time out.
You'll also get downvoted for complaining about being downvoted. That's almost verboten here, and explicitly mentioned in the guidelines.
When you get downvoted, accept that possible your comment detracts from the conversation. It doesn't just not add anything, but takes away. It's noise.
If your first reaction is to edit your comment and complain, then that's a clear sign you aren't in the right frame of mind to contribute meaningfully.
Your original comment was, if I may be so bold, cliche. Maybe that's the wrong word, but it comes up by someone with your attitude generally every time a thread about an open source project comes along. It literally is something that can go without saying.
His original comment didn't lack originality because he posted something that he did that was quite interesting. I, for one, believe that anyone is capable of anything they set out to complete. I don't think noticing a polarized reaction from a community you participate in is always a transgression. No ruleset rationalizes the community's reactions 100% of the time.
As others have pointed out, it's just an inappropriate comment.
Yes it's open source, and yes, anyone can hack on it themselves. But 99.99999% of the time it's not realistic.
Nearly every piece of software on my computer could be enhanced to fit me personally, but there's no way I could justify the time and energy to work on it. Also, in most cases I have no desire to learn the stack/underpinnings for a particular enhancement.
Lastly, the comment comes off as condescending. Are we really not allowed to wish for things? Must we personally fix everything we find an inconvenience or problem with?
Though I agree with you, where is the stick in the ground? The OSS community's theme song has always been "you can do it yourself", even though that has long been not realistic for many people. So, nothing here is different as far as I can tell.
> The OSS community's theme song has always been "you can do it yourself"
In my experience over the last 15 years, that theme song can often veer from "you can do it yourself" (empowerment) to "do it yourself" (dismissal); replying to a reasonable feature request, in any context, with 'fix it yourself' is one of the things that turned a lot of people off OSS around the time of the first 'year of linux on the desktop'.
The GIMP was the best example of this, with professional graphics editors, illustrators, etc. requesting features and being told 'no one needs those features' and 'if you want it so much, do it yourself', and it hurt their image a lot with many potential users, both technical and non-technical.
Personally, I'm glad that attitude has largely disappeared (though apparently, not entirely).
The open source community cannot simultaneously use "anybody can fix bugs and add features" as one of their loudest pitches and then get offended when people suggest doing so. Either being able to dive in and fix it yourself is an edge case or it is not.
Being able to dive in and fix it yourself is definitely an edge case. Even among people who use terminals, I don't know that many who are able or willing, or who have the time or energy, to learn the codebase enough to add a feature.
'The open-source community' isn't pitching this idea and also rejecting it. 'Tone-deaf open-source proponents' are pitching it (or, in this case, suggesting it, and rudely) and regular, well-socialized people are criticizing it as a good idea poorly said.
Errr are you running the Yosemite beta? I love the dark menu bars.
How do you find it? Do you find the kindergarten icon colours irritating? What about the blurriness? Do you feel like you've switch to varifocal lenses and are constantly rubbing your eyes?
What about the lack of Maximise/Zoom button? I don't want everything fullscreen - the menubar has MenuMeters running in it and a clock which you can't see in Fullscreen mode. I use ShiftIt to maximise the window when Zoom is being dumb and fear for my future with this insane "maximise" button removal.
Agree. Session restoration is really great. I would go further, though. I use `source` for virtualenv and it would be awesome if terminal could restore that as well.
One problem I have with this is that its a massive security hole. Where does the output get stored? If its in an encrypted file, okay .. but if not: deal breaker.
You can disable it system wide. But it also works on a per-app basis: if you don't want the UI state restored, then just quit the app with Cmd+Option+Q (instead of the regular Cmd+Q) and OS X will not save the application state.
I wish that there would have been a setting in the program options ("Preferences"... I don't know why, but that word annoys me in this context) so that the user wouldn't always have to do cmd-opt-q. Maybe the best option would be to have a checkbox that swaps the behavior ("don't save the output unless I press cmd-opt-q").
THANKS for letting us know about cmd-opt-q! I'll have to start using that all the time since it does seem like a potential security hole.
You can disable window restoration system wide (System Preferences -> General -> "Close windows when quitting an app").
So you don't have to use the shortcut at all in that case.
Personally I prefer getting used to using it on a case-by-case basis. For example, when I leave work I tend to quit most apps on my laptop with Cmd+Option+Q, so that when I get home they don't re-open with work and I can start working on personal projects.
1. If you regularly have passwords, keys, PII, etc. in terminal windows, your workflow should change.
2. If you care about security in any way, you should be using FileVault rather than cargo-culting it into apps (there's no way for that "encrypted file" to be secure unless you have to type in a password every time you shut down the system). If you do that, anyone who can read that file has already compromised your account and there's no additional exposure from this.
>1. If you regularly have passwords, keys, PII, etc. in terminal windows, your workflow should change.
Security is not just about passwords. Its about operational knowledge of procedures and habits at the console, too. Knowing that a certain command is always used, or some such operational administration occurs, definitely assists attack.
>2. FileVault
FileVault is not always available, nor is it always allowable.
But history files are not only about password, as I said.
I can see it being a performance issue if you need to fsync session updates to disk constantly, but personally I'd be pretty much happy if the session was only saved at normal shutdown. Maybe saving it after a certain idle period would also be useful.
Would that mitigate your performance concerns, or did I not guess the source of the issue correctly?
If anyone else is wondering where the toolbelt is, once you enable toolbelt with "Toolbelt" -> "Show toolbelt", you'll have to resize the iterm window.
It appears so. Probably worth filing a bug about this, but I suspect that something about mosh's terminal emulation filters out the VT100 command sequences tmux uses to perform the handshake with iTerm2.
ITerm is great. It really is. But I wish more time was spent on optimizations. People these days seem to forget that terminals are often used for displaying huge amounts of rapidly scrolling text and that speed is of paramount importance.
To put this in perspective, my computer has two CPUs with 4 cores each, 24GB RAM, a graphics card with 1600 Stream Processing Units (engine running at 850MHz) and 1GB of RAM, and yet it scrolls text in a terminal slower than my 386 machine 20 years ago.
Not just fast scrolling text. For some reason there is a noticeable delay when just typing text into a shell in iTerm. I didn't notice it until one day I started Terminal.app for no reason at all, and typing in it gave me that feeling that it was predicting my keystrokes, meaning of course that my brain expected a lag that wasn't there.
I had the good (?) fortune to come into OS X at the end of the 10.3 days (in fact, my Powerbook didn't come with an OS install so I put Debian on it for a week until Tiger was released), so I suppose I missed this phase. When I got Tiger on, Terminal was more than sufficient, and iTerm felt immature and impractical for daily use.
I never understood why so many people used it, but reading this, it makes a lot of sense now.
i had the same beef with it and i went back to using xquartz with dwm and urxvt.
The reason why it's so slow is very simple. It's basically an nstextview derivate.
To be fast it needs to fill the buffer and render it offscreen in fixed intervals. a lot of osx programs share this problem. there was an ancient vnc viewer called vncthing that easily beats every osx vnc viewers performance, because of that.
This might be an unrelated problem, but I find that when I copy a large amount of text and paste it into iTerm, it takes a long time to paste. This often happens when pasting into Vim, so it could be a vim issue. For example, copying the code of a Javascript library. When I do this in a text editor outside of iTerm, it's nearly instantaneous.
Try turning off syntax highlighting and any plugins like jshint that try to operate on a buffer realtime in vim before pasting (or just paste it to an temporary buffer instead of an existing js file) if it's still slow then it's probably iterm and not vim.
Vim will type every character you paste, one by one.
F12 should switch you to paste mode and paste it as a block, though on my new Mac this was already mapped to some GUI function so I had to disable that for it to work.
Pasting into a buffer in insert mode is not the best idea. I've remapped <leader>p and <leader>P to paste from the system buffer and it's just as fast as yanking and putting text in Vim.
That doesn't work as well over SSH sessions though, which is where pasting into vim really starts showing its limitations. Vim's normal inefficient behaviour plus a link with latency is an unfortunate circumstance.
While text performance is important, when I have to scroll through huge amounts of text it's usually because I made a mistake. If the output of my "fgrep -ri" is too long, it's also useless and I'd better pipe it to another grep or use a better regex.
I have tail -f on various logs running, I often run processes that spew massive amounts of debug output (which I then search through), and even ls -al can sometimes be fairly long. There are lots of use cases where you want lots of text. And in this day and age I really want to just dump it all into my terminal, without planning ahead how to work around the slowness.
tmux is my main use-case for a fast terminal. Even something as simple as resizing a split in my main 266x188 session while nothing else is happening makes Terminator (VTE-based) into a juddering laggy mess.
urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds.
Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.
It's responsive and fast for you in a single fullscreen 2560x1600 term while catting a large file in a split? Performance is a lot more reasonable if you're using more traditionally-sized terms and let Terminator manage the splitting.
Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.
I've tried iTerm and a few other alternatives periodically over the years and I keep coming back to Terminal.app for performance and stability. It'd be interesting to see how far a performance sprint could take iTerm…
Did you try out the new iTerm? I was having issues like this, and started using the iterm nightlies about 8 months ago. I've seen considerable performance improvements, and now prefer it over Terminal.app.
I did a lot of work on performance which you can see in the nightly builds; it was too risky for the 2.0 schedule. We now parse the input stream in a separate thread from where it is rendered. That being said, while the refresh rate is probably lower than it was on your '386, the throughput is undoubtedly higher. If you'd like a higher refresh rate, it's a trivial tweak to a single constant, but in general throughput is more useful.
Yes, throughput is what I'm really after, refresh rate is secondary (still nice, but secondary).
It's great to hear that this work is happening, thank you! And also thank you for all the work, because gripes aside, iTerm2 is the best tool out there.
Performance actually seems to be much better in the new version! My standard test is to open a split-screen tmux session and try scrolling man pages.. New version doesn't jump around the page.
On the downloads page, the link text for the stable release says "iTerm2 2.0 (OS 10.6+, Intel-only)" but the description below it says "It requires OS X 10.7+ and an Intel CPU."
236 comments
[ 2.6 ms ] story [ 345 ms ] threadAside: Check For Update... still gives 1.0.0.20140629 as the latest version. Have to download a 2.0 build explicitly.
http://www.iterm2.com/downloads.html
Can I duplicate this functionality using iTerm, without using AppleScript?
[1] Here's the code; I cobbled it together from some StackOverflow snippet or something: https://gist.github.com/anonymous/f16a46c327a14ec8a5b5
I have a config that looks like this:
and I just run `mux start blah` and that will either start a new tmux session and set up everything as I need, or resume an already running session.https://docs.google.com/document/d/1ABI0kqUUxoAjxhWW3AsWFis6...
http://code.google.com/p/iterm2/wiki/TmuxIntegration
I use tmux partly because I come from a background of low resources, but also because I want my essential tools to use as little resources as possible so that they always work as well as possible on any system.
Yet iTerm proposes that you use their GUI tabs, split their GUI terminals instead of drawing it all with tmux in one text console.
I guess you sacrifice some resources for usability.
For me personally, I use ctrl-a instead of ctrl-b so I have this line in my ~/.tmux.conf:
Lastly, iterm2 uses it's own keystrokes for it's tmux integration. (i.e.: cmd-D to split vertically)I take it with nested tmux sessions, cmd-D would split the outer tmux window? How would you split the inner tmux window?
It's worth checking your config file out.
And I'm not sure how to answer your question because the way iterm integrates with tmux is that it allows you to create split panes with their own bash sessions. If you want to run tmux in those sessions, it would be tmux running in that pane, but textually instead of graphically. Here's a screenshot to make things more clear: http://i.imgur.com/0hmw62I.png
cmd-D would just create another pane to the left.
It appears that once you've created a tmux session you need to manually add tmux commands in a dialogue box.
I'm a little surprised more people don't run into this more often. I've never seen the benefit in running tmux locally. Do most people only ever use tmux on one remote host?
Edit: it's been a while since I've tried it; apparently tmux integration doesn't work over mosh at all. So s/mosh/ssh/g above and it still applies.
What changed you from "terminal.app is good enough" to "I prefer iTerm"?
Because that's what I'm asking myself.
If you use tmux, iTerm is the obvious choice. They've been working on better tmux support for a while now.
With that said, I'm going to give iTerm another try - the tmux support is intriguing...
thanks for this, didn't know this was possible!
I stuck with iTerm because of the many, many little features and conveniences that make working with the terminal easier.
Tabs can be put at the bottom of the screen, which solves that pesky issue where changing tabs on a fullscreened terminal.app causes the OSX topbar to slide down and intercept your click. Tab titles change color depending on the kind of activity that's going on within. Hotkey mapping is a lot more powerful, and lets you send arbitrary hex/escape codes with hotkeys. There's a drop-down mode, like Tilda or Visor. This might just be placebo, but I'm pretty sure it also glitches out less often than Terminal.app.
All in all, everything is just a little bit nicer than the stock terminal.
[1] officially http://zsh.sourceforge.net/, but you want http://ohmyz.sh/
However, MacVim improves again on those two points, so I end up using that.
So what is it?
iTerm exports its color profile as shell variable, so you can have vim adjust its color theme to match the terminal theme.
It has better full screen support.
It has support for foreground/background color of the text the cursor is over, which Terminal.app does not have at all. This is why in vim if you cursor is over syntax highlighted element whose color is similar to the cursor color, it become incredibly hard to tell where the cursor is (esp. on large screen).
iTerm has "highlight cursor feature", to quickly show you where the cursor is (CMD+/). This is useful if you went away from the screen for a while and you come back, and can't immediately spot the cursor.
iTerm has better font rendering (more like GUI Vim) because it is a Cocoa view.
iTerm allows you to split terminal windows both horizontally and vertically.
The list goes on, but these are some highlights. Essentially, you have more control over your terminal.
I made the switch from Terminal.app myself when iTerm finally added the feature, but Terminal.app had this functionality available via a SIMBL plugin (oh man, remember those?) called "Visor" for several years, but it was always a hack that would stop working for a few weeks/months whenever a new version of OS X was released.
It looks like Visor has now been replaced with TotalTerminal, another hack in the form of a wrapper application bundle: http://totalterminal.binaryage.com/
And no, Terminal.app does not have full-screen mode that is useful. Lion-style fullscreen apps are absolutely useless to me, since you can't bind them to ctrl-[1-9] hotkeys to switch between spaces.
System Prefs > Keyboard > Shortcuts > Mission Control > Switch to Desktop #
Any time I hit my special trigger key combination, it will 'launch' that app. If it is open it gives it focus, and if it is not running it opens the app. This means I can rearrange my apps and desktops however I like and I always instantly travel to the app I want next.
Terminal is command-shift-I anywhere. Chrome is command-shift-c for example. Firefox is command-shift-f. Let's say I'm editing an HTML file over ssh and I want to test it. It doesn't matter whether chrome or Firefox are running, full screen, on the same virtual desktop, if I strike command-shift-c Chrome is instantly in front of me. I flip between programs all day and don't use my dock except to empty trash (and yes I know command-option-shift-delete but that is living on the edge!)
Not sure if Quicksilver has this, but one nice feature is that if, say, Chrome is currently active, and I hit its key-combo (control-shift-c), Chrome is hidden (the equivalent of command-h). This is great if you're installing something in the background and want to see if it finished without reverting back to the dark ages of command-tab.
It's especially nice on a laptop, because I can expand all my windows to fill the screen while still having near-zero overhead when switching between apps.
It works just fine, I know where every app is, so I just go directly to that space with ctrl-$SPACENUMBER
Now, note that I say full-screen, I mean "with menu bar visible, maximized using Divvy." I can't use system-provided full-screen API, because I lose ability to use only keyboard to navigate around.
What if I have 6 full-screen Terminal windows (connected to SSH servers, tmux sessions, and so on), and I need to switch between them? Your comment prompted me to install Quicksilver, but it doesn't seem like it can handle that. I'd be glad to hear if I'm wrong.
I also quite like that iTerm allows non-Lion full screen mode. That combined with some tasteful transparency lets me see stuff happening while I'm poking around at the command line. It's nice to visually see the result of a Control-C or the relaunching of a web server.
> Deep tmux integration. iTerm2 can speak directly to tmux and display its virtual windows as native windows or tabs, making tmux much easier to navigate.
I actually prefer Terminal.app otherwise, but the tmux integration is so good it's worth it just for that.
That's reason enough for me...
2. Problems with displaying my favorite font, ProggyClean, in Terminal.app.
Every time I install it on a new computer I have to google a bunch of places and set up the key bindings again
* search starts from the bottom of the buffer (most recent result).
* I can cmd+click filenames with line number (in error messages) and have them open in my text editor with cursor on the right line.
* notifications when background tab becomes idle - notifies about finished long-running builds/installations, etc.
* much better, customizable keyboard shortcuts. Supports meta keys properly. I have keyboard shortcuts for opening a tabs connected to my servers, disabled annoying "Print" shortcut, etc.
* 256-color support. This was added in Lion I believe.
* There's a really weird bug with word-wrapping that only manifests itself in Terminal.app: http://superuser.com/q/46948/5966 As of 10.9, I believe it remains unfixed.
Smarter "dobule-click to select" logic. iTerm seems to highlight exactly what I want when I double-click in the area. Last I tried Terminal, it missed the mark.
Select to copy. I know some people can't understand why anyone would want this, but I've become accustomed to it. One thing that does still annoy me, even with iTerm, is that I find after I select something I need to move my mouse for it to copy.
I imagine 256 color support was a deal breaker before Lion, but I'm still an iTerm guy because of those reasons above.
Unlike most others it seems, I don't utilize the tmux integration, despite using tmux heavily.
[0] https://discussions.apple.com/thread/3690502?start=0&tstart=...
I do prefer Terminal.App. To me it feels more polished and stable and I'm used to it and it comes with the OS. I appreciate iTerm and the work put into though and it's what I currently use, but if I could get my Vim setup working in Terminal.App I would switch back.
I've been using Terminal on Yosemite, and for what it's worth, the Solarized theme works properly. I'd forgotten how much trouble it was in the past.
My current setup is to run tmux inside Terminal, with the 'Option as Meta key' flag enabled. Then configuring tmux to use Option-A (instead of Control-B) preserves the standard emacs shortcuts. So Control-A and Control-B still work to move to the beginning of the line and back a character. Mapping Control to Cap Locks, and using Option-A for tmux has served me well so far.
I agree that Terminal seems more polished (start up time and ability to keep up with typing speed - iTerm seemed slightly laggy compared to Terminal). But I'll give iTerm another try - the configuration options are impressive.
Still doesn't work for me :(
.[eE](rror|xception). highlight error lines :\d+ highlight line numbers in ruby (captures bits of time stamps though...) [lL]ine \d highlight line numbers in python
I bet there are more creative uses. please enlighten me.
[1]: https://github.com/alloy/terminal-notifier
I see from the changelog that some type of restoration has been included: "Support for OS 10.7 features including fullscreen, retina graphics, and window restoration"... but upon actually trying it out, it doesn't do what Terminal.app does.
0: http://apple.stackexchange.com/questions/75571/the-history-i...
Edit: I wrote a thing here about the difficulty of carrying history across terminal sessions and how can you associate a tab you open now with a tab you had open in a previous session, but then I realised that I misread your post.
I would expect the answer in the posted link to work. The 'share_history' option, when set, tells zsh to reread the history file before performing history lookups.
Maybe try the set-local-history option documented here?
1: http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html#...
Terminal.app almost certainly does not do what you're describing by default.
Yes, it does. http://i.imgur.com/kYmlBk8.png
This is where Terminal.app (or possibly OS X 10.9 + Terminal.app) ability to show you your terminal history on recovery from Kernel Panic is really appreciated.
If only there was a reliable USB-Serial cable/controller/interface for the Mac. Unfortunately, RS-232 is so rare (except for consoling into Cisco Routers?) that there is no incentive for any vendor to actually write a half stable driver.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
http://www.usconverters.com/index.php?main_page=page&id=60
I'll definitely try the Trendnet TU-S9. Here's hoping 4 years of weekly hell on my mac laptop comes to an end...
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
http://www.usconverters.com/index.php?main_page=page&id=60
I'll definitely try the Trendnet TU-S9. Here's hoping 4 years of weekly hell on my mac laptop comes to an end...
But, maybe I'll try upgrading to Mavericks - this seems to suggest that some progress has been made in the FTDI driver department: https://developer.apple.com/library/mac/technotes/tn2315/_in...
That fixed the KP for me and got break to work which didn't out of the box.
Before the updated drivers I worked around the KP by closing cu/screen before unplugging the cable.
Since 10.7, system (assuming the app cooperates, that is) does that for you and reopens everything.
It's open source. Why don't you add it yourself?
I wanted a borderless terminal and as I couldn't find one I hacked the functionality into iTerm: http://i.imgur.com/jOc04sf.jpg
/edit: Wow, being downvoted for suggesting to hack something yourself on Hacker News ... that's a new one. I guess I'll take a time out.
In your mind a developer can realistically contribute to any possible open source project, whatever the language and the domain?
He may have to learn an humongous quantity of things to implement a feature and then never use that knowledge anymore.
Founding the project while asking for a feature could be a better advice.
The exact same sentiment could have easily been posted in a friendly and welcoming manner, but that didn't happen and that's why he's getting downvoted.
You'll also get downvoted for complaining about being downvoted. That's almost verboten here, and explicitly mentioned in the guidelines.
When you get downvoted, accept that possible your comment detracts from the conversation. It doesn't just not add anything, but takes away. It's noise.
If your first reaction is to edit your comment and complain, then that's a clear sign you aren't in the right frame of mind to contribute meaningfully.
Your original comment was, if I may be so bold, cliche. Maybe that's the wrong word, but it comes up by someone with your attitude generally every time a thread about an open source project comes along. It literally is something that can go without saying.
Yes it's open source, and yes, anyone can hack on it themselves. But 99.99999% of the time it's not realistic.
Nearly every piece of software on my computer could be enhanced to fit me personally, but there's no way I could justify the time and energy to work on it. Also, in most cases I have no desire to learn the stack/underpinnings for a particular enhancement.
Lastly, the comment comes off as condescending. Are we really not allowed to wish for things? Must we personally fix everything we find an inconvenience or problem with?
In my experience over the last 15 years, that theme song can often veer from "you can do it yourself" (empowerment) to "do it yourself" (dismissal); replying to a reasonable feature request, in any context, with 'fix it yourself' is one of the things that turned a lot of people off OSS around the time of the first 'year of linux on the desktop'.
The GIMP was the best example of this, with professional graphics editors, illustrators, etc. requesting features and being told 'no one needs those features' and 'if you want it so much, do it yourself', and it hurt their image a lot with many potential users, both technical and non-technical.
Personally, I'm glad that attitude has largely disappeared (though apparently, not entirely).
This attitude seriously needs to die.
'The open-source community' isn't pitching this idea and also rejecting it. 'Tone-deaf open-source proponents' are pitching it (or, in this case, suggesting it, and rudely) and regular, well-socialized people are criticizing it as a good idea poorly said.
How do you find it? Do you find the kindergarten icon colours irritating? What about the blurriness? Do you feel like you've switch to varifocal lenses and are constantly rubbing your eyes?
What about the lack of Maximise/Zoom button? I don't want everything fullscreen - the menubar has MenuMeters running in it and a clock which you can't see in Fullscreen mode. I use ShiftIt to maximise the window when Zoom is being dumb and fear for my future with this insane "maximise" button removal.
THANKS for letting us know about cmd-opt-q! I'll have to start using that all the time since it does seem like a potential security hole.
So you don't have to use the shortcut at all in that case.
Personally I prefer getting used to using it on a case-by-case basis. For example, when I leave work I tend to quit most apps on my laptop with Cmd+Option+Q, so that when I get home they don't re-open with work and I can start working on personal projects.
I'll just have to get used to cmd-opt-q.
2. If you care about security in any way, you should be using FileVault rather than cargo-culting it into apps (there's no way for that "encrypted file" to be secure unless you have to type in a password every time you shut down the system). If you do that, anyone who can read that file has already compromised your account and there's no additional exposure from this.
Security is not just about passwords. Its about operational knowledge of procedures and habits at the console, too. Knowing that a certain command is always used, or some such operational administration occurs, definitely assists attack.
>2. FileVault
FileVault is not always available, nor is it always allowable.
But history files are not only about password, as I said.
Would that mitigate your performance concerns, or did I not guess the source of the issue correctly?
Details on the protocol are here: https://docs.google.com/document/d/1ABI0kqUUxoAjxhWW3AsWFis6...
*https://launchpad.net/terminator
[1]: https://github.com/alloy/terminal-notifier
To put this in perspective, my computer has two CPUs with 4 cores each, 24GB RAM, a graphics card with 1600 Stream Processing Units (engine running at 850MHz) and 1GB of RAM, and yet it scrolls text in a terminal slower than my 386 machine 20 years ago.
I never understood why so many people used it, but reading this, it makes a lot of sense now.
On the other hand, such lag is ever-present with SSH—and now it will subjectively increase as I get used to Terminal again.
The reason why it's so slow is very simple. It's basically an nstextview derivate.
To be fast it needs to fill the buffer and render it offscreen in fixed intervals. a lot of osx programs share this problem. there was an ancient vnc viewer called vncthing that easily beats every osx vnc viewers performance, because of that.
F12 should switch you to paste mode and paste it as a block, though on my new Mac this was already mapped to some GUI function so I had to disable that for it to work.
Some relevant info: http://stackoverflow.com/questions/5585129/pasting-code-into...
urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds.
Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.
There is something seriously wrong with your setup. I use Terminator and byobu (with tmux) all day and never experienced what you describe.
Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.
It's great to hear that this work is happening, thank you! And also thank you for all the work, because gripes aside, iTerm2 is the best tool out there.
Can anybody confirm whether it works on 10.6?
http://fishshell.com