Bash shell tricks

The bash shell has so many nifty tricks. They can come in handy in order to save time with repeated tasks, recover data, etc.

  1. My set of customizations for bash can be found on github. With those customizations, you can make find easier, colorize diff, man and prevent clobbering when using output redirection. I especially love the colored man pages.

  2. If you want to sudo-ize the previous command, use;

sudo !!
  1. rename utility: I never knew this! It makes renaming multiple files using regex patterns so much easier!

  2. In scripts, instead of the awkward test command ‘[‘, use ‘(( … ))’ and ‘[[ … ]]’ in its place. It makes logical and string comparison so much easier. (ref: modern bash test operators)

  3. To get your current shell name, do

ps -p $$


echo $0


Some more examples can be found here: bash trick commands

There are also some intricacies like the difference between rm and unlinkrm vs unlink

Feel free to suggest more in your comments.

Note: The file .bashrc is not loaded by bash at startup, by default. So it must be included in either the file .profile or .bash_profile.

ssh tricks

I must have used ssh for the past 15 years but I never knew this trick. So if you want to ssh into a remote server and run some command on it, and exit, you don’t actually need to login into the console and type the commands. It can be done by injecting commands through a ssh connection (and piping the output back too).

So if you want to ssh into the raspberry pi and do a simple ‘ls’, use this:

ssh  pi@host -p port#  'ls'

If you use key authentication and have saved the keys, your login can be automated without the need for password (more on that later).

If you’d like to get the output and store it on the local host, use regular linux redirection:

ssh  pi@host -p port# 'ls' > test.txt

Isn’t this great 🙂

More details can be found here:

Run commands through ssh

Pipe output from local to remote server using ssh

Experiments with PiGlow 🍰 ✨

I just got the PiGlow LED display module for raspberry pi. Connected it to RPi and tried to enable the SPI and i2c buses using

sudo raspi-config

But this is what I got:

ERROR: could not insert 'spi_bcm2708': No such device


Turns out that there have been some changes in the Linux kernel. From 3.18 onward, (for the arm-compiled kernel), the kernel uses “device trees”, which breaks SPI and I2C unless config changes are made 👷. Here are some posts describing the problem:

linux kernel 3.18+ breaks spi, i2c

Well it turns out that in spite of the error above, the raspi-config utility does add the required lines to /boot/config. Once that is done, follow the remaining steps as outlined here:

Setup I2C

After that is done, reboot and test if I2C is up and running by doing:

i2cdetect -y 1

and you’ll see some output of rows and columns.

For the B+ board, and all newer boards, the channel 1 is used instead of channel 0. Once I2C is setup, download the code from Pimoroni’s website. Compile it and run the example script as described!


Jason has a nice Python class for the PiGLow on his github page:


Here’s a picture of my PiGlow module:


Booting up the RPi from a USB flash drive

As mentioned in the previous post, the SD cards are not the best media for a large amount of read/writes, as used in the RPi. A USB flash drive is much better suited for this purpose. Plus, SD cards can get permanently damaged due to power spikes. USB drives are much more resilient to this. I bought this low-profile USB drive from Sandisk (USB Drive) and will use it to store the root partition for my RPi. The micro-SD card will thus be used only for the boot partition. This is unavoidable, since the booting requirement from the SD-card is hard coded in the Broadcom SoC in the RPi. But once we have this setup, the SD-card we use just needs to hold the boot data. So this card could be very small (even a 1GB card is large enough).

This procedure is a bit involved the first time, since we need to generate UUIDs. However, the blog by Mel Grubb describes it in a detailed but simple to follow manner, that I won’t bother to reproduce all the steps here. The blog post is here: RPi USB boot.

Following the steps in Mel’s blog, I was able to boot up from the USB drive correctly the first time! Thanks Mel!


1. When you start fresh with a new USB drive, make sure you delete all partitions and re-format it with a GPT type partition table. GPT is the modern replacement for the old MBR and is much more flexible and efficient. Steps to do that are described in detail here: Create GPT type partition table.

2. Before re-sizing the file system to the partition size, unmount it and do a check using:

sudo fsck -f /dev/sd(xx)

Now things become so much easier. I can easily move data to/from the USB drive and my laptop. More reliability, more flexibility, more space.

I’ve made a pdf from Mel’s post. All credit goes to him and the other sources he has referenced. To access the pdf, click here: RPi-boot pdf.

An explanation of the reason why the noatime attribute in /etc/fstab is important for the RPi (limited processing power) can be found here: The noatime attribute.

Also, general fstab reference: fstab

NB: These low-profile tiny USB 3.0 drives run very hot ♨️ This is normal, but be careful while touching them after a lot of activity.

NB 2: So I was wondering where the file system size is stored, in ext(n) file systems. It has something to do with the “block group descriptor table”. You can get this info by doing:

sudo dumpe2fs /dev/sda2 | more

The information will look something like this, for a file system size of around 2GB:

Block count:              516189
Reserved block count:     25809
Free blocks:              59818
Free inodes:              50516
First block:              0
Block size:               4096

The product of ‘block count‘ and ‘block size‘ should equal the file system size. After re-sizing the file system, the ‘block count’ should change.

Raspberry Pi Home Server: Part 6, Adding a hard drive

The perfect guide to booting up the Raspberry Pi from a USB stick.


This article is part of a series. See the Index for more information.

Running the Raspberry Pi off of an SD card is simple, affordable, and very convenient. SD cards are also very small compared to hard drives, though, and they can only be written to a finite number of times. That number is ridiculously large, but some have said that it can still be used up faster than you think by things like virtual memory swap files which are written and re-written constantly.

Whether you believe that or not, one thing is certain; In order to be a useful home server, the Raspberry Pi is going to need access to more storage space than you get from a simple SD card. The Raspberry Pi Home Server is going to need a proper hard drive, and as long as you’re adding a hard drive, you may as well take advantage…

View original post 3,971 more words

Backup, backup and wait for it…. backup!

We must remember to backup the RPi’s SD card! First of all, SD cards were never meant to be used the way they are in the RPi. They were meant for data blocks written infrequently by cameras. USB flash drives are better suited for RPi-kind data storage than SD cards.

Secondly, the RPi’s data bus is very finicky when it comes to the input voltage. I was trying to power my Pi using a portable mobile phone charger by HooToo (hootoo). Though it’s rated output is 2A, I think I connected and disconnected it multiple times by mistake without a clean shutdown. This corrupted my sd card! But I am not talking about just data corruption – it physically corrupted it such that it cannot even be read anymore.

So the lesson learnt is – backup as much as possible!

The simplest way I know is to use a Linux computer and the ‘dd’ command. Here are some steps to follow:

Make sure there’s enough space on the local drive!

Check partition names:

sudo fdisk -l

Unmount SD-card partitions before reading or (esp.) writing!

sudo umount /media//root

Use this for backup:

sudo dd if=/dev/mmcblk0p6 of=root.img bs=32M

(The block size could also be 4M)

Use this for restore:

sudo dd if=root.img of=/dev/mmcblk0p6 bs=32M

For those who want to use windows for backup, the standard win32diskimager tool is great. But note that it clones the entire SD-card. You cannot select individual partitions.

TI Launchpad



I got a new TI launchpad MSP430G2 board. This is a simple micro-controller board with built in flash emulation and debugging capability. You can use TI’s CCS or  Energia to communicate with it and flash your program.

I start with the simple example blink LED tutorial, which is quite fun 🙂

Lets see how I can hook it up with my Raspberry Pi to make something interesting.

Securing secure-shell server


A follow-up to my earlier post about securing access to your RPi. (fail2ban-lifesaver). Some amount of security can indeed be obtained through obscurity. One way to do this is to change the default port # for the ssh server. Since most hackers will try to attack port 22 first, it’ll take some time to reach the obscure port number set by you on your RPi. Yes port scanning will eventually find it, but hey, why not delay the attack 🙂

#Port 22
Port 16022

Read up about how to change the default ssh server port here (its really quite simple): Change default ssh port.

Also remember to change it in the fail2ban config file.

#port = ssh
port = 16022

Further security measures like public key, port knocking: Harden the ssh server.

I also used iptables to block a whole range of IP addresses, from which hackers are trying to attack my RPi. This is how you do it: Block a range of IP addresses.

sudo iptables -I INPUT -s -j DROP