Always uses dashes in filenames

In these days of cloud storage, file synchronisation, and sharing on social media it's more important than ever to properly name files.

Spaces make sense in written language but computers don't like them. Try to use a space in a filename in a URL and it'll replace it with %20. Try to do anything on the command line and you'll have to wrap the filename in double quotes.

The two common conventions are underscores (_) and hyphens (-). One convention used commonly in Unix/Linux filenames is to use underscores to separate words in the file title, and hyphens to separate the title from version number. For example Apache modules take the form of file_name-version.extension, eg. mod_ftp-0.9.6.tar.gz.

Turns out if your filename is ever to be processed by a regular expressions (such as by the Google indexer!) the underscore will be removed and filename concatenated. When using the the \w operator to find words the underscore is ignored, but the hypen is not.

Always use dashes in filenames instead of spaces or underscores.

Raspberry Pi Dumb Terminal And Then Some

As someone whose interest in computing struck in the early 1980s I've always loved small self-contained computers. In my teens I discovered dumb terminals. However, it wasn't until the last ten years when I found myself SSHing in to remote servers that the idea I might have a use for one made any sense.

I Googled, I pored over and, I watched old films. I kept coming back to the DEC VT100. I scoured eBay and other sites but they rarely come up and when they do are out of my price range.

Picture of a VT100 terminal

It dawned on me, "heck! I have a 3D printer, a competency with CAD, Linux, and basic electronics, and oh, the Raspberry Pi would be perfect for this."

First things first was to source the parts so I could design my VT100 around it.

The guts would be a Raspberry Pi Zero W since all I intended to use it for would be connecting to other systems.

The screen was straightforward enough on AliExpress. A nice 8", 4:3 screen with driver board, HDMI, VGA, and AV inputs was only ~£26. It's bright and sharp and only requires 12v at 2-4amp.


With a big enough power supply I could power the Pi and the screen from one input. I bought a simple step-down board to convert 12v to 5v with a USB output.

12v to 5v converter

The keyboard was a bit of a headscratcher. I wasn't about to 3D print a chassis and full keyboard so I was forced to compromise on the VT100 authenticity. I bought a cheap small USB keyboard. A future upgrade might be to make a housing this 3rd party keyboard would fit in to.

I leapt in with both feet (and a set of calipers) and designed a small VT100 which would fit the screen I had nicely.

Screenshot of VT100 design

The further I got in to designing it I realized how difficult it would be to print on my printer (the case itself would require six or seven parts glued together) and that it would take up a lot of precious desk space. I decided version one should be a working machine, not a faithful reconstruction. With a coffee and a notebook I started with some sketches.


With 3d printing in mind I selected one design and created it in CAD, but I found it wanting. Instead of a side-by-side arrangement for the circuit boards I came up with a design where the boards are stacked.

Abandoned design Abandoned design

Final design Final design

Circuit board arrangement Circuit board arrangement

In all I think it took about twenty-six hours to print. I'm happy to say it fits together nicely.

Photo of working terminal 1 Photo of working terminal 2

I realised that this was wasted as just a terminal so I put a Pi 3b+ in there and installed the desktop environment. I put a ZX Spectrum emulator on and realised I'd neglected to a put a speaker in! Something for v2. For version two I'll probably make some of the corners softer by rounding them and make it snap together tighter.

Extracting and renaming files from zip archives

I had a pile of zip files all containing different files, but also containing a file called preview.png that I wanted to extract and rename. Since the names of the zip are descriptive I wrote a bash script to loop over the files, extract the preview file and rename it. The interesting bit is stripping the .zip extension.


for F in $FILES  
  echo "Processing $F file..."
  unzip "$F" preview.png
  FN=${} # strip .zip
  mv preview.png "${FN##*/}.png"

For tar or gzipped tar the following will work in place of the 'unzip' line above:

tar -xf "$F" path/to/preview.png # extract from tar  
tar -zxf "$F" path/to/preview.png # extract from tar.gz  

Cache control using a map in Nginx

Google's delightful Lighthouse utility moaned at me about cache-control. For that particular site I use Nginx as a reverse proxy to NodeJS.

Nginx allows us to set a map for filetypes and apply that map to one or more server definitions. To define the map create the following near the top of your configuration file:

map $sent_http_content_type $expires {  
    default                    off;
    text/html                  epoch;
    text/css                   max;
    application/javascript     max;
    ~image/                    max;

In the above example, epoch sets the expiry time of all html to 1st January 1970 (which we all know was a Thursday). max on the other hand sets the expiry time to 31st December 2037 (a Friday). Other options off or a specific time.

The last entry, ~image will apply to rule to any content type beginning with image/, for example image/jpeg or image/png.

To apply the map add the following line inside the server block:

server {  

    expires $expires;

Plex transcoding using a RAM disk

My home server is a server in software only. Hardware wise it's an old Dell Inspiron desktop which was my main machine for a good five years. It's a core 2 duo with 6gb of RAM and on-board graphics.

I run the Plex media server on it, as well as some other services, all on Ubuntu Server 18.04. Without a fancy GPU, Plex does all the transcoding of media files using software, something which can tax an old system like mine given I encode to HEVC to save space.

Plex allows us to specify a directory where the transcoding data is written as it is used. It doesn't need to be very big. It occurred to me I could use a RAM disk for this and make it nice and snappy. Not to mention saving wear on the drive.

To create the drive first create a directory, then mount it as tmpfs

sudo mkdir /mnt/ramdisk  
sudo mount -t tmpfs -o size=512M tmpfs /mnt/ramdisk  

It's important the location is owned by root as we want to remount it at reboot. The default permissions for tmpfs make it writable by everyone, but just in case it's not chmod it to 1777.

To ensure the drive is remounted at boot add the following to the /etc/fstab file:

tmpfs /mnt/ramdisk tmpfs rw,size=512M 0 0  

We can use the df -h command to view the usage. The following shows my 1gb RAM disk with Plex using 67mb to transcode an SD video of a Porky Pig cartoon encoded in HEVC:

Filesystem      Size  Used Avail Use% Mounted on  
udev            2.9G     0  2.9G   0% /dev  
tmpfs           594M   33M  561M   6% /run  
/dev/sdc1        50G  9.3G   38G  20% /
tmpfs           2.9G   20K  2.9G   1% /dev/shm  
tmpfs           5.0M     0  5.0M   0% /run/lock  
tmpfs           2.9G     0  2.9G   0% /sys/fs/cgroup  
/dev/sdb1       1.8T  1.1T  664G  62% /mnt/media
/dev/sda1       688G  282G  372G  44% /mnt/tor
cgmfs           100K     0  100K   0% /run/cgmanager/fs  
tmpfs           594M     0  594M   0% /run/user/1000  
tmpfs           1.0G   67M  958M   7% /mnt/ramdisk