I like iTerm 2 (and I can not lie). I use a Mac and spend most of my days in the terminal (and Emacs). When a window system first came into my life, it was X Windows. It’s terminal software, xterm, had a pair of features that are hardwired into me, copy on select and paste on middle button (though these days getting a decent middle button is a pain). OS X’s Terminal does not do either of these things, so it’s out.
Let’s look at another feature of I like iTerm 2. Normally, opening a new window or tab creates a new login in your home directory, exactly what you’d expect from a terminal program. However, you can choose instead to open a shell in the current directory, letting you add another window on whatever you are doing.
Previously, I wrote about backing up files to Dropbox with rsync. I automated the process with cron the ancient UNIX “time-based job scheduler”. While OS X ships with cron, newer versions of the operating system favor launchd. launchd is much more than a cron replacement, on OS X it also fills the rolls of init, init.d/rc.d scripts, and inetd. It can be told to watch for changes in directories or drives to be mounted and run processes when those events happen.
launchd is powerful, but it’s use of XML config files makes it overkill for simple tasks that can be handled by cron. However, if the task isn’t so simple…
This is a bit of a departure from my usual Ruby, Ops, and Security posts. However, recently I acquired a mostly completed RepRep 3D printer and wanted to document an issue I had to debug. One of the reasons I blog is to share the answers to problems for which the Google couldn’t find me an easy answer. And this problem was “Why does the y-axis stepper motor only move in one direction?”.
One simple way to back up files is to copy them to Dropbox. However, manually copying files does not constitute a good backup, you’re going to forget.
Also, you want to be smart about it and just copy things that have changed or are new. My favorite tool for smart copies is rsync.
If you aren’t familiar with rsync, it’s a program for intelligently syncing one directory tree with another. It looks for additions, changes, and, optionally, deletions in a source directory (and it’s subdirectories) and make the destination an exact copy. After an initial copy is created, rsync is very efficient as further syncs only copy changes.
In my last post about an alias that opened a URL from the command line, I said:
open is OS X specific. On Linux you’d want xdg-open or gnome-open, on Windows, start, under Cygwin, cygstart.
(The $ after the = is an example of using Bash’s ANSI C quoting mechanism.)
(CSH single quote escaping is even more convoluted…)
Basically, we grab the remote URL from with
git config, strip out
the repo path and slap https://github.com/ in front of it with
and then use
open to feed the new URL the default web browser.
This makes a couple presumptions:
- You are in a Git repo.
- You are using SSH style URLs.
- open is OS X specific. On Linux you’d want xdg-open or gnome-open, on Windows, start, under Cygwin, cygstart.
Making it smarter is left as an exercise to the reader.
I wrote and maintain (though not as attentively as I’d like) a Ruby Gem, Strongbox, which adds Public-key Encryption support to Rails’ ActiveRecord. Simply put, Public-key Encryption is a form of encryption with two password, one to encrypt data and another to decrypt it. This is handy for web applications, any visitor can encrypt data using encryption password (the public key). However, if an attacker gains access to the server and steals the data and the app’s code, they still can’t decrypt the data because they lack the decrypt password (the private key).
The problem is you’re doing it wrong.
When I need to test web apps on an iPhone or iPad, I use the iOS
Simulator that ships with Xcode1. The Simulator is intended for
developers testing native apps, however, Mobile Safari is installed
and I can use it to debug apps without a physical device. I’m
lazy and don’t want to open up Xcode just to
get to the Simulator. Fortunately, it’s a standalone app that lives in
/Applications/Xcode.app/Contents/Developer/Applications/iOS Simulator.app. That’s way too much to type, aliases to the rescue.
A visitor, Rakkesh, stopped by with a question about Building Emacs 24.4 From Source on the Mac. He had an issue that when he built Emacs on one machine (a Mac-Mini Server) the resulting application would not run on another (his laptop). He wrote:
Is there anyway I can create a self contained Emacs.app bundle which can be redistributed on all my machines without installing any additional dependencies, such as, gnutls, libxml2 - the latest versions from Homebrew, on those machines?
The problem occurs because Emacs’ build process will greedily take advantage of any libraries it can find installed on the build system. If you’ve installed something the build considers useful like gnutls or libxml2, it will link against them. However, results in an executable that always loads those libraries and won’t run on systems that don’t also have them installed.
Making up passwords is hard. You want something you can remember which is and you need something difficult to guess or brute force.
For countless years, I have been a fan of Diceware for generating memorable passwords, really pass-phrases, and you should be too.