Cygwin bash: inspect the contents of .gitignore files

When git complained

The following path is ignored by one of your .gitignore files:puppet/modules/postgresql

it neglected to tell me which file. I used bash find to search all of the .gitignore files in my project:

$ find . -name .gitignore -print -exec cat '{}' \;
./.gitignore
.vagrant
./puppet/modules/apt/.gitignore
*.swp
pkg/
Gemfile.lock
./puppet/modules/mysql/.gitignore
*.swp
pkg/
./puppet/modules/stdlib/.gitignore
pkg/
.DS_Store
metadata.json
coverage/
Gemfile.lock
.bundle/
vendor/bundle/

The "-print" option produces the file path, then the "-exec" option calls the "cat" command to dump the contents of the file, passing the file path to cat in the '{}' argument.

Vagrant: how to fix "VM inaccessible" error

I've hit an annoying error a couple of times when trying to "vagrant up" a box after waking Windows 7 laptop from hibernation:

Your VM has become "inaccessible." Unfortunately, this is a critical error with VirtualBox that Vagrant can not cleanly recover from. Please open VirtualBox and clear out your inaccessible virtual machines or find a way to fix them.

This message came from vagrant 1.1.5. Under the hood, vagrant calls the command-line VBoxManage utility provided by VirtualBox to manipulate the VMs. vagrant helpfully traps the error flag produced by VBoxManage and serves up that vague yet soothing error message. Although considerate, the message doesn't really help me diagnose the problem. Fortunately, when run in debug mode (set VAGRANT_LOG=debug then run vagrant status), vagrant will cough up all the nasty error messages from VBoxManage.

After some digging through the debug output, I discovered that even though the actual VM is intact (I can load and run it from the VirtualBox GUI app), somewhere in its guts, VirtualBox flagged this VM as "<inaccessible>". Vagrant, rightly believing what it's told, spits out the error message.

After looking at VBoxManage's help, I found that one its commands, list vms, unsurprisingly lists all of the VMs registered with VirtualBox:

$ /cygdrive/c/Program\ Files/Oracle/VirtualBox/VBoxManage.exe list vms
"precise64" {3613de48-6295-4a91-81fd-36e936beda4b}
"<inaccessible>" {2568227e-e73d-4056-978e-9ae8596493d9}
"<inaccessible>" {0fb42965-61cb-4388-89c4-de572d4ea7fc}
"<inaccessible>" {c65b1456-5771-4617-a6fb-869dffebeddd}
"<inaccessible>" {9709d3d5-ce4d-42b9-ad5e-07726823fd02}

One of those VMs flagged as inaccessible is my lost VM! Time to fix VBoxManage's wagon, by unregistering the VM as inaccessible, then re-registering it with the correct name:

1. Open the configuration file for your lost VM. Mine was saved to C:\cygwin\home\Philip\VirtualBox VMs\rails-vm-v2\rails-vm-v2.vbox
2. Find and copy the value of the uuid attribute of the Machine node. Mine was 9709d3d5-ce4d-42b9-ad5e-07726823fd02.
3. In a Windows command prompt (or Cygwin terminal), unregister the VM with the unregistervm command, using the [uuid] value from step 2:
   $ C:\Program Files\Oracle\VirtualBox\VBoxManage.exe unregistervm [uuid]
4. Now register the VM using the registervm command, with the path to the VM configuration file:
   $ C:\Program Files\Oracle\VirtualBox\VBoxManage.exe registervm C:\cygwin\home\Philip\Virtual VMs\rails-vm-v2\rails-vm-v2.vbox

Now you should be able to start the VM as expected.