Lilypond 2.12 in the OSX Terminal
Getting this error?
$ /Applications/LilyPond.app/Contents/Resources/bin/lilypond
dyld: Library not loaded: @executable_path/../lib//libstdc++.6.dylib
Referenced from: /Applications/LilyPond.app/Contents/Resources/bin/./lilypond
Reason: image not found
Trace/BPT trapI don't know why this is screwed up, but I have a workaround:
ln -s /usr/lib/libstdc++.6.dylib /Applications/LilyPond.app/Contents/Resources/libWhile I'm at it, here's my script in ~/bin:
$ cat ~/bin/lilypond
#! /bin/bash
exec /Applications/LilyPond.app/Contents/Resources/bin/$(basename "$0") "$@"You can symlink it to midi2ly or whatever other executables you want to execute. Or you could add that directory to your path, of course.
Terminal Merge Conflict Resolution
A very important tool in the toolbox of any collaborating developer is a merge conflict resolution tool. OS X has the fantastic FileMerge, there are various graphical tools for linux like kdiff3, but I have yet to hear of one for the terminal. There's vimdiff, but it is really not up to the task of merge conflict resolution (doesn't handle 3-way diffs). There's probably something in emacs, just because there's always something for emacs. Emacs users please enlighten me, I'm not above using emacs for merge-conflict resolution. Might even be the gateway drug.
It doesn't seem overly hard (at least, no harder than writing kdiff3 or FileMerge) to make an ncurses tool that will take a 3-way merge and let you efficiently choose A, B, or edit for each diff section. Can it really be that nobody has done it yet?
git GUIs
One of the nice things about git is due to its UNIXy design and its massive and ever-growing popularity, there are a lot of really nice bells and whistles, and I think we can expect to see even more. For example, GitHub.
While most git interaction is with simple commands in the terminal, it often pays to be able to get a birds-eye view of the revision history, or what I will call the DAG. The original tool for this is gitk. Gitk is functional, but it's really really unpleasant. It's written in Tcl/Tk—what did you expect? Some of us have higher standards for usability.
I tried out a few git GUIs and I have settled on two that I think are best of breed. The first is tig. Tig is an ncurses program, so it excels for remote operation over ssh, for quick dives into the repository without reaching for the mouse, and in keyboard use. Think of it as mutt for git. It's a fantastic program and I use it most frequently.
I have customized my tig setup slightly:
$ cat /Users/fugalh/.tigrc
set show-rev-graph = yes
color cursor white blue
$ alias | grep tig
alias tiga='tig --all'
The second is GitX. It's a mac app in every good sense, and it's an excellent git GUI. As you can tell from the screenshot, it's a bit easier on the eyes for visualizing complicated DAGs (not that this screenshot is of a complicated DAG).
If you use GitX be sure to "Enable Terminal Usage…" so you can start it on the current repository on the terminal by typing gitx.
OS X Terminal Emulation Woes
OS X's Termina.app is the terminal I've been using since I switched to Leopard, because it has tabs now and it's beautiful. Oh, and iTerm gave me too much grief with odd, illogical and unpredictable bugs.
One of the drawbacks to Terminal.app is that it's broken. This is what Aptitude looks like with TERM=xterm (I think this is the default):
This is what it should look like:
How to get from there to here? The short answer is to choose dtterm as your terminal emulation (in Preferences, on the Advanced tab).
The long answer is that the problem here is that xterm supports this capability called back-color-erase (bce). If you tell programs that you are an xterm (with TERM=xterm), they will assume you support bce. The same goes for rxvt and xterm-color and even vt100 (even though that one doesn't seem to support color). bce isn't the only problem, either. There's also redraw problems that are difficult to show with a screenshot.
Setting TERM=dtterm seems to get rid of at least the major breakage. It would seem that the actual capabilities of Terminal.app are closest to dtterm, or at least closer to dtterm than to xterm or rxvt. It solves all the issues I've been having with aptitude, mutt, and screen locally and on remote linux boxes. But there's a caveat—not all remote systems will have the dtterm entry in their terminfo databases. Ubuntu 7.10 didn't by default, for example. The package you want on Debian-based systems (like Ubuntu) is ncurses-term.
Alternatively, you can install it in your home directory. To do this, on OS X type
infocmp > /tmp/dtterm
scp /tmp/dtterm username@example.com:/tmp
ssh example.com tic /tmp/dtterm
tic (terminfo compiler) will create a terminfo database entry in ~/.terminfo/d/dtterm, and you should be good to go.
Terminal 2
I now have Leopard, so expect a flurry of posts as I discover neat things and annoyances.
The biggest reason why I got Leopard, apart from that my fellowship paid for it
and you never turn down free gadgets or software, is for Terminal.app redux,
aka Terminal 2 (think Schwarzenegger). When working on a laptop, I must have
a tabbed terminal. This forced me to use
iTerm, which worked well most of the time.
However, iTerm hates me. It has an impossible-to-track-down bug that will
occasionally render every curses program (including vim) useless for an
indeterminate amount of time, and not even restarting iTerm will fix it. In general I've found iTerm to be somewhat shoddy, and Terminal is beautiful and, well, Mac-ish. So I'm excited for the switch to Terminal 2.
I had a right to be, too. It is a beautiful piece of software. I have a few qualms, though. First, and most annoyingly, the keybindings for next/previous tab aren't configurable, and they're set to the ridiculous default of ⌘-{ and ⌘-}. Yes, that means you have to press shift too. However, there is hope! Go to the Keyboard & Mouse preference pane, in the Keyboard Shortcuts tab. Scroll down to Application Keyboard Shortcuts, and add shortcuts for Terminal.app. Now I can switch tabs with ⌘-→ and ⌘-←, as it should be. Naturally, you can use this trick to change any unfavorable keyboard shortcut in any native OS X application.
I'm having some emulation issues, but this is not new to Terminal 2. When I ssh to my linux box and run irssi the screen doesn't update properly. It works ok if I run irssi in screen though.
I like the unlimited scrollback, though I hope it's not all going into RAM. Sometimes I'll do the odd copious command that spews on forever. I don't mind if it's going to a temporary disk buffer, but I don't want it all in RAM. I'm sure they figured that out though.
The built-in themes are nice. The configuration is well layed out, with one exception. I wish there was a place to set default preferences, common to all of the themes that don't override them. But since I and most other people who would care will stick to one theme, I guess it's not a big deal.
I haven't noticed any of the rumored problems of Terminal resizing without permission. I think Gary must have been expecting terminal to read his mind about where and how big new terminal windows would be. I'm glad it doesn't, because if I closed a terminal that I had resized temporarily, and then all my terminals started opening at that odd size, I'd be quite grumpy indeed. Size is one of the preferences you can set, and it works almost perfectly. I like mine as tall as I can get them, and I set it to 53 lines (with Anonymous 10pt). For some reason terminal would end up not quite at the top of the screen and sized only at 50. I opened a few tabs, sized it the way I wanted it (oops, with tabs I only get 51), and then went to the menu and chose Shell, Use Settings as Default. Now it behaves itself. My only unresolved annoyance is that I can't tell it to always have tabs, even when there's only one tab open. I don't like the shifting and resizing during the transition from 1 to 2 tabs (or vice versa). Oh well.
Terminal Unicode Wrangling on OS X
This is the 21
Start at this article on Internationalizing the Mac OS X terminal. Following the instructions there will get you 90% of the way there. You will install a new version of bash and coreutils (for ls, cd, etc.), you'll set up your locale information (actually you only need to set LANG, in my experience. I export LANG=en_US.UTF-8 in my .bashrc).
If you use OS X's default vim (/usr/bin/vim), it will Just Work. But if you have vim 7.0 from some other source, it may or may not work. In particular if you do sudo port install vim you'll probably get a broken vim. Be sure to use the multibyte variant if you install from ports.
If you use iTerm, it might work worse than before you made the changes above. But notice that it works fine if you run another bash instance, or screen. I'm not sure but I think you fix it with the LC_CTYPE hack detailed in this article. Those .inputrc lines probably won't hurt either, though I'm not sure what problem they fix. One of those two changes seems to have fixed the iTerm problem.
Speaking of screen, you probably want to add defutf8 on to your ~/.screenrc.
I'm curious if things work out of the box in $YOURFAVORITEDISTRO. I've previously mucked about with unicode so much in Debian and Ubuntu I have no recollection of what the default state of affairs is. Try the following and let me know in the comments how it worked.
echo æøÜÉ > /tmp/ƒøø
ls /tmp/ƒøø
cat /tmp/ƒ<tab>
vim /tmp/ƒøø
screen vim /tmp/ƒøø
For me, I see exactly that and exactly what you'd expect on the terminal and in vim (both in and out of screen), which has never all happened in OS X for me before. It does work over ssh on my Debian box, but as I say I've played with things there so it may or may not have worked out of the box.