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.

I have lots of shell aliases/functions for repetitive tasks. Copying files to and from servers, removing editor backup files, connecting to specific databases, the list goes on.

Sometimes however the thing I want to do is directory specific. A good example of this is when I’m developing scripts. Typically, I edit in the comfort of my desktop, and copy scripts to the server for testing. As I’m often working on multiple files, I use rsync to keep the remote directory in sync.

1
2
3
# Edit
rsync -av . example.com:some/directory/path
# Test

This keeps the local and remote directories in sync, uploading only the files that have changed. There are other work-flows I could use, for example, my editor supports remote editing with SSH, but rsync works for me.

HTML5 <audio> tags is pretty straight forward. Given:

1
<audio id="player"></audio>

this bit of Javascript:

1
2
3
player = document.getElementById('player');
player.src = 'some-audio-file-url';
player.play()

will start playing whatever the src points to. (Pro-tip: If you are using jQuery, you need get the actual HTML element with player = $('#player')[0] or player = $('#player').get(0))

However, if the user is on either an iOS or Android mobile device, the above won’t actually play anything.

Previously, I showed how I set $EDITOR. On my laptop, I actually do something different to take advantage of my favorite Emacs feature EmacsClient. EmacsClient is command line accessory that commands existing Emacs sessions to open files. That way you can have Emacs open with your windows arranged the way you like and push in files that you want to work as you go.

In addition, EmacsClient can be used as $EDITOR to cause programs, say a ‘git commit’ to open a window instead of starting a new editor session.

TL;DR - This won’t work:

1
scp remote.example.com:file.txt other.example.com:

This will work, but is slow:

1
scp -3 remote.example.com:file.txt other.example.com:

We can do better.

My editor of choice is Emacs. However, in a pinch I can drive vim or vi just fine1. While I prefer Emacs, I can’t think of a UNIX-like operating system that ships with it by default. Most, if not all, do come with something in the vim/vi family. So, unless I’m going to do some heavy editing on the server, I usually don’t bother installing Emacs.

Most distros set vim/vi as the default editor, however I’m seeing more defaulting to something more “user friendly” like Nano or Pico. Given that, I want set $EDITOR and make sure I get my preferred editor:

1
export EDITOR=$(type -P emacs || type -P vim || type -P vi)

What does it do? type -P prints the full path of the file what Bash would execute. The || works as you would expect, if type returns a path, execution stops and $EDITOR is set to the value. Otherwise, the next editor is tried. If nothing is found, then $EDITOR is set to blank, which will cause the system default to be use.

I started using UNIX in an age when $EDITOR meant your line editor that would be used if your terminal didn’t support “advanced” features, namely full screen cursor control, I still also set:

1
export VISUAL=$EDITOR

Even though it’s probably meaningless.


  1. In fact once someone said to me “What do you mean you’re not a vi user? You’re navigated with hjkl!” Well, that muscle memory comes from years of playing Nethack (and Hack) before it).

TL;DR

With a little JavaScript it’s possible to detect if a browser supports Server Name Indication and conditionally redirect to a HTTPS page. Code at the end of this post.

Trouble, thy name is Shared Hosting with SSL

Recently, I had to put a client into Amazon CloudFront for a high traffic event. I’ve done this a number of times, but this was the first time I need HTTPS support. Amazon offers HTTPS in two forms:

  • All Clients (Dedicated IPs)
  • Only Clients that Support Server Name Indication (SNI) “Older browsers and other clients that don’t support SNI can’t access your content over HTTPS.”

All clients sounds safe right? Well, it is, but it’s also very expensive and enabling it requires that you go through an approval process.

SNI is cheap and easy, but… I was aware of it’s existence, and knew it was a pain because of limited browser support. Time to check that assumption.

First, however, we need to understand the different types of hosting and, to do that, you need to know a little about how HTTP and SSL/TLS work.

How you clear the DNS cache on OS X has changed yet again…

DNS caching is a good thing in general, it speeds up your browsing by not having to request the same information over and over. However, if you are making changes to DNS, they will not appear until the cache expires.

On 10.10 Yosemite clearing the DNS cache is now done by running:

1
sudo discoveryutil udnsflushcaches

For the record:

(OS X > 10.6 && OS X < 10.10):

1
sudo killall -HUP mDNSResponder

OS X <= 10.6:

1
sudo dscacheutil -flushcache

Emacs 24.4 is officially released and Mac OS 10.10 Yosemite has arrived. As always, time to build.

Before begin you will need Xcode installed (free in the Mac App Store) to build Emacs. Of course if your the sort of person who uses Emacs, you’re probably the sort of person who has Xcode installed.

To build Emacs you also need Autoconf and Automake and Apple has stopped shipping these with Xcode. If you don’t already have them (hint: which autoconfig and which automake) you will need to install them.