Working Ninja

Here's a simple way to count lines of code via the command line that I recently used for a Django project:

find . -name '*.py' -not -path "*/migrations/*" | xargs wc -l


wc -l **/*.py


dd if=<path to input file> | pv -s <size e.g. 1377M> | dd of=<path to target device>



To swap control and command, add the following to your ~/.Xmodmap file:

remove control = Control_L
remove mod4 = Super_L Super_R

keysym Control_L = Super_L
keysym Super_L = Control_L
keysym Super_R = Control_L

add control = Control_L Control_R
add mod4 = Super_L Super_R

The above current works for both an Apple laptop and an Apple keyboard.

Also, to use Command+Tab to cycle windows, make sure to update keyboard shortcuts to use Ctrl+Tab instead of Alt+Tab (for Xfce, Window Manager -> Keyboard). All other keyboard shortcuts should come through (from the Control to Command swap perspective).



The Old Way

import os

os.system('find /home/user/documents -type f -iname "*.doc"')

The New, Recommended Way

import subprocess

    '-type', 'f',
    '-iname', '*.doc'

Bonus Tidbit

At this point, we can incorporate some nice exception handling:

import subprocess

        '-type', 'f',
        '-iname', '*.doc'
except subprocess.CallProcessError as e:
    print e.returncode
    print e.cmd
    print e.output

See the official Python Documentation for more usage and recommendations on the subprocess module.


Install NFS server components:

# apt-get install nfs-kernel-server portmap

Add the "root" of all shares (if this is your only share, this should be all you need):

# echo "/home,fsid=0)" >> /etc/exports

Add additional shares:

# echo "/home/joe,sync,no_subtree_check)" >> /etc/exports

Update NFS exports table:

# exportfs -avr

Restart NFS server:

# service nfs-kernel-server restart

Don't forget to allow NFS through iptables.


# apt-get install nfs-common
# mount server:/share /share



Slow initial directory listing is caused by aliases (specifically color output). Explanation here: Use \ls -la instead of ll as a workaround.



Before adding a script to cron and finding that it doesn't work because of a PATH issue, here's a handy command to test:

env -i ./script

This will run your script in the same environment that cron will.


I must have it saved somewhere but it was nowhere to be found. The password was lost. My root account was forever secure--or was it?

# service mariadb stop
# mysqld_safe --skip-grant-tables &
# mysql -u root
> USE mysql
> UPDATE user SET password=PASSWORD("mynewpassword") WHERE User='root';

This didn't stop the mysqld_safe process, so I killed the parent mysql process (/usr/libexec/mysqld) via its process ID ($pid).

# kill $pid

Start MySQL back up.

# service mariadb start

Finally, for security purposes, remove the UPDATE user ... SQL statement from ~/.mysql_history.

Profit! And don't forget to securely store your password.


GitLab was throwing me a 500 server error this morning after an upgrade via yum. To troubleshoot, I ran the self diagnose command from terminal:

# gitlab-rake gitlab:check

Which gave me the following error to fix:

All migrations up? ... no
  Try fixing it:
  sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
  Please fix the error above and rerun the checks.

Since I installed GitLab via a yum package, I ran a slightly different command to run the GitLab migrations:

# gitlab-rake db:migrate RAILS_ENV=production

Now I was presented with the source of the issue, relating to PostgreSQL. I needed to enable the pg_trgm extension:

== 20160226114608 AddTrigramIndexesForSearching: migrating ====================
-- execute("SELECT true AS enabled FROM pg_available_extensions WHERE name = 'pg_trgm' AND installed_version IS NOT NULL;")
   -> 0.0066s
rake aborted!
StandardError: An error has occurred, all later migrations canceled:

You must enable the pg_trgm extension. You can do so by running "CREATE EXTENSION pg_trgm;" as a PostgreSQL super user, this must be done for every GitLab database.

And sure enough, others were having the same issue. These are the steps they (and I) executed to fix the issue:

# yum install postgresql-contrib
# su - postgres
$ psql -d gitlabhq_production -c "CREATE EXTENSION pg_trgm;"
$ exit
# gitlab-rake db:migrate RAILS_ENV=production
# gitlab-ctl reconfigure
# gitlab-ctl restart



$ VBoxManage modifyhd YOUR_HARD_DISK.vdi --resize SIZE_IN_MB



I went to update my Ubuntu machine today and found out there wasn't enough space on /boot to perform the update. You can remove older kernels to free up space:

// Check which kernel you're using
$ uname -r

// List all installed kernels
# dpkg --list 'linux-image*'

// Remove the kernel (I recommend the oldest [kernel with the smallest number])
# apt-get remove linux-image-VERSION