Bash Completion for Removing Harddrives Via the Command Line

If you're frequently adding and removing harddrives from your mac you might want to be able to do so from the command line. Here is a simple shell script (unharddisk) to allow detaching volumes.

If you're using bash completion there's a small source file (unharddisk.source_me) to include in your shell startup script (usually .bashrc). This file provides you with the command unhd with command completion.

In the given configuration I'm excluding the drive names MAINDRIVE and Sharky, as these are drives I never want to unmount. You can tweak the unharddisk.source_me file to your own needs:

COMPREPLY=( $( compgen -d /Volumes/$cur|cut -b 10-| egrep -v '(MAINDRIVE|Sharky)') )

If you don't want to exclude any drives from the completions, just remove the egrep command from this line entirely:

COMPREPLY=( $( compgen -d /Volumes/$cur|cut -b 10-) )

Or if you want to only skip one drive e.g. by the name of MyHD:

COMPREPLY=( $( compgen -d /Volumes/$cur|cut -b 10-| egrep -v 'MyHD') )

Thanks to Annika Backstrom for her concise bash completion example.

unharddisk.zip

Using EasyLogging++ on Apple Mac OSX 10.8.5

To use EasyLogging++ on Apple Mac OSX 10.8.5, you need to add:

-std=c++11 -stdlib=libc++

to your compiler options.

So, for a hello world example paste this into a file hello.cpp:

#include "easylogging++.h"

_INITIALIZE_EASYLOGGINGPP

int main(int argv, const char** argc) {
    LOG(INFO) << "Hello, world";
    return 0;
}

and compile it with:

g++ -std=c++11 -stdlib=libc++ hello.cpp -o hello

Run the program:

./hello

That will give you something similar to:

24/11/2013 11:46:52,297 INFO  [default] Hello, world

Disable "Close Window" (Cmd+W) for iTerm

Searching for this gives several results that didn't satisfy me, e.g.
http://apple.stackexchange.com/questions/44412/disable-command-w-in-the-terminal
(a "global" setting)
or
https://groups.google.com/forum/#!topic/iterm2-discuss/j6UDxO5_CXc
(generally having to confirm the closing)

So I propose this:
Open Preferences>Keys
At the bottom of "Global Shortcut Keys" click "+", then type Cmd-W and leave the default Action "Ignore".
You're set!

multi-platform MIDI library

I tried RtMidi on Windows and OS X 10.6.5 (Snow Leopard). Unfortunately, SysEx messages sent via RtMidi on OS X would only be sent after starting another application that also uses Midi (SysEx Librarian or MIDI Monitor, both from snoize.com). Otherwise, SysEx messages would simply not be sent, while RtMidi would fail reporting any errors. It seems, RtMidi is skipping some CoreMidi initialization.

I followed this advice how to build portmidi using MinGW on WinXP, and it worked:
http://cratel.wichita.edu/cratel/cratel pyportmidi#build_portmidi_.28MinGW.29
It's unfortunate that this Makefile is not distributed with portmidi.

Sending SysEx with portmidi worked on both OS X and WinXP.

As a side note, one of RtMidi's objectives: "object oriented C++ design" fails to really hold. RtMidi defines a abstract root class RtMidi and extends it by RtMidiIn and RtMidiOut. Defining a common super interface for both sending and receiving midi doesn't hold up very well, as the sample program sysextest.cpp exemplifies:

bool chooseMidiPort( RtMidi *rtmidi )
{
bool isInput = false;
if ( typeid( *rtmidi ) == typeid( RtMidiIn ) )
  isInput = true;

What good is the RtMidi abstraction if just a few lines further down you break it again?

Furthermore I'd consider it both from an ethical and an engineering point of view a cleaner design to openly use portmidi instead of cannibalizing some of its code (see RtMidi.cpp):

// This function was submitted by Douglas Casey Tucker and apparently
// derived largely from PortMidi.
CFStringRef EndpointName( MIDIEndpointRef endpoint, bool isExternal )

...

// This function was submitted by Douglas Casey Tucker and apparently
// derived largely from PortMidi.
static CFStringRef ConnectedEndpointName( MIDIEndpointRef endpoint )

Changing default shell in mingw msys shell

I'm using:
MINGW32_NT-5.1 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
on OSX 10.6.5 (Snow Leopard)
And tried to change the default shell from sh to bash.

This didn't seem to work for me:
http://digital.blogsite.org/index.php/2009/07/23/how-to-change-default-shell-in-msys-ming

But this did:
http://oldwiki.mingw.org/index.php/MsysShell

I actually just put a .profile in my homedir with these contents:
#!/bin/sh.exe
/bin/bash

MacPorts Perl CPAN on OS X 10.6.4 Snow Leopard

Try to install CPAN Modules in your non-root account for your MacPorts Perl on OS X 10.6.4 Snow Leopard and you're in for some nasty surprise:
You'll find your local MyCPAN.pm will eventually be silently ignored and ~/Library/Application\ Support/.cpan used instead. As much as I detest fiddling with the configuration of standard tools in OS X, I had no choice:
cpan
o conf build_dir /Users/bwagner/.cpan/build
o conf cpan_home /Users/bwagner/.cpan
o conf histfile /Users/bwagner/.cpan/histfile
o conf keep_source_where /Users/bwagner/.cpan/sources
o conf prefs_dir /Users/bwagner/.cpan/prefs
o conf commit
After this change and removing my ~/.cpan and starting afresh, things worked out.
The terrible thing is, this behavior starts only after installation of some particular modules. As it turns out it happens after the direct or indirect installation of File::HomeDir. Good luck trying to figure that one out.

Here are some related posts:
http://www.nntp.perl.org/group/perl.module-authors/2009/09/msg7886.html
http://www.nntp.perl.org/group/perl.module-authors/2009/09/msg7891.html
http://rt.cpan.org/Public/Bug/Display.html?id=32841
https://rt.cpan.org/Public/Bug/Display.html?id=43549
http://jjnapiorkowski.vox.com/library/post/trouble-installing-with-cpan.html

Any user who tries to install modules from CPAN as non-root user on OS X will run into this problem. Apparently it's known since early 2008 ...

US legal system: what you risk as an employee

comment to Chip Salzenberg's legal issue. A follow-up by Mark Jason Dominus.
Or the David McOwen case, also written up by Ann Harrison, SecurityFocus.