mvim Bash Error — bad interpreter: Operation not permitted

Yesterday I reformatted my computer as it was starting to slow down. RAM and CPU usage was consistently higher than normal. Things just felt sluggish.

When I do a reformat like this, I ensure it is clean. This means that I only copy irreplaceable items from my backup, such as documents and pictures, but all of my applications I re-download and install from either the Mac App Store or their respective websites.

One key application I have been using a lot lately is MacVim. While useful on its own, it also comes with a BASH script for opening files in MacVim from the command line, called mvim.

As usual, I moved mvim to the bin directory in my home folder and ran it to see if it worked, only to receive the following error:

-bash: /Users/colincwilliams/bin/mvim: /bin/sh: bad interpreter: Operation not permitted

This was surprising as, on my previous install, mvim worked just fine from the get-go.

After some searching I noticed similar errors people had from other scripts. One of the common causes was incorrect line endings for the system: Windows is different than Mac OS is different than Unix. I won’t delve into the differences here, but you can read more about them in the Common Problems section of the Wikipedia Article.

On OS X, the simplest fix for this that I could think of was using Bare Bones Software’s TextWrangler¹.

To do this, open mvim in TextWrangler and in the menus select Text > Normalize Line Endings. Save the file and try executing mvim again. It should work just fine this time, opening a document in MacVim as expected.

Consistently Connect iPhone to Mac Over Bluetooth

For the past few months I’ve been using an application called Type2Phone which allows me to use my Macbook keyboard to type on my iPhone. It works very well, using bluetooth for the connection and makes sending texts and instant messages (MSN, GoogleTalk) far faster on the iPhone. Type2Phone has been the first and only reason I’ve ever had to connect my iPhone to my Macbook over Bluetooth.

Since I started using it, however, I had major issues with connecting my phone to my laptop over bluetooth (note that this is an issue with iOS and/or OS X, not with Type2Phone). Once the devices were paired, trying to connect them would often result in errors such as:

• “Macbook not within range.”
• “Macbook is not a supported device.”¹

Finally, after far too much frustration, I believe I know how to connect my iPhone and Macbook consistently and it’s quite simple:

Have Type2Phone² running when you try to connect the devices.

That’s it.

Since I’ve started doing this I haven’t seen any errors and using Type2Phone has become a far more enjoyable experience.

More Back Button Confusion

In December I wrote about iOS Back Button Confusion, outlining how having multiple back buttons on the same screen in iOS creates user mistakes or slowdowns as they determine which button they should use. I recently noticed the same issue with my RSS reader of choice, NetNewsWire (which is an outstanding app for reading RSS feeds on the desktop).

In similar fashion to the iOS apps, NetNewsWire has an embedded browser for viewing links. Thus, it also requires having two back buttons: one to exit the browser and one for going backwards in the browser history.

With NetNewsWire, as with iOS, I find myself exiting the embedded browser when I intended to go backwards in the browser history. This causes a small amount of frustration which adds up to a poor user experience over time.

My proposed solution still stands, as the dynamics of the problem have not changed between touch screen and pointer input methods: provide a way for the user to “undo” the act of closing the browser. For a deeper explanation of not only the solution, but the problem, take a look at the previous post.