Now that's what I call a Hacker

Originally written on a Russian website, Alex from JitBit Software has translated a hilarious post describing allegedly real scripts that do all varieties of things:

OK, so, our build engineer has left for another company. The dude was literally living inside the terminal. You know, that type of a guy who loves Vim, creates diagrams in Dot and writes wiki-posts in Markdown... If something - anything - requires more than 90 seconds of his time, he writes a script to automate that.

Here’s one gem: - another cron-job that is set to specific dates. Sends automated emails like “not feeling well/gonna work from home” etc. Adds a random “reason” from another predefined array of strings. Fires if there are no interactive sessions on the server at 8:45am.

A GitHub project was started to recreate the scripts in a variety of languages.

What is a coder's worst nightmare?

Mick Stute on Quora, answering the question “What is a coder’s worst nightmare?”:

I was hired by a psychologist to fix a program that seemed to have “strange output” written by one of his ex-grad students. It was a program that reads a data file, asks about 50 questions, does some calculations, and comes up with some score based on this PhD’s research. It’s on a research 3B2 at the university. He demonstrates the program and sure enough there seemed to be strange flashing words on the screen when it moves from question to question, and they don’t seem nice.


This ought to be simple. There are only about five places it could output anything, and all of them had this subliminal flash of a message. Each one was hard coded. No problem. Delete the offending mvpwintw() and all is well. Or should be. I compile, thinking I’m done. But when I ran it, there it is again -- the subliminal messages. This time with different text still the same subject, just different messages.

I check my code and believe it or not it’s back to the initial state I found it. 15 files, mangled, 3-letter variables -- the whole thing right back where I started.

That’s just the start and it only gets better from there. The end result truly is a programmer’s worst nightmare, though I won’t ruin the ending. Well worth the read.

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 TextWrangler1.

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.

  1. A great text editor to always have on hand. [return]