… and no, that’s not a movie title.

As you know, all your computer knows about is numbers, yet when you type on a keyboard, a character appears on your screen. This is thanks to character encodings.

There are several norms that defines how characters (ie, glyphs) are encoded into numbers. Besides dinosaurs such as EBCDIC, the “classic” way of encoding is ASCII – that is what most modern¹ operating systems use internally.

The problem with ASCII is that it maps every character to a single byte with MSB reset, meaning that you can have a maximum of 128 glyphs. It’s “good enough” for English (hey, the A stands for American) but terrible for international characters. This is even worse considering that 32 of them are control characters, ie mostly legacy. Did you ever need to interpret DC2, SI or GS in a program ?

The eighth bit being “reserved” can be used to support “extended characters”. Several vendors (including Microsoft) used the concept of “code pages” to use extra glyphs in the 128-255 range. For example, Latin-1 was used in western europe to display accentuated characters.

If all your data comes from one part of the world, it works fine, but with the following limitations if you need to handle international data :

• it becomes necessary to have metadata specifying which codepage has to be used.
• you have to choose exactly one codepage per document.

In other words, a more extensible system is needed. Hopefully, this system exists and is called…

Unicode

Unicode separates two notions :

• what is a character. Unicode include a large collection of glyph names. For example, version 6.0 includes 109449 characters.
• how a character is encoded as bytes. More precisely, this is the role of encodings such as UTF-8. Usually, they are compatible with ASCII (the byte representation coincides on characters 0-127).

What’s nice is that it’s easy to enter Unicode under X11. The last two sections explain how you can configure your system to type (for example) √, β and ✈ !

Configure a compose key

A “compose” key, or Multi_key under X11, will begin a character compose sequence. For example, when I type <Multi_key> <s> <q>, a square root (U+221A √) is entered.

To configure a compose key, you can use xmodmap(1). Put the following into ~/.Xmodmap to make your right control key act as a Multi_key :

keysym Control_R = Multi_key

Unfortunately, this file is not loaded automatically, so you have to run xmodmap ~/.Xmodmap when opening a X session (this can be done automatically if you put in in your ~/.xsession, for example).

Define a .XCompose mapping

The second part is to define mappings between key sequences and unicode codepoints. This is the role of the ~/.XCompose file.

As described in xcompose(5), a line looks like :

<Multi_key> <ampersand> <p> <l> <a> <n> <e>     : "✈"   U2708     # AIRPLANE

ie, a key sequence, a colon, a string and a character name. The comment does not hurt, as usual.

To start your own list of bindings, I suggest kragen’s repository, which includes an excellent set. And if you need to find a specific unicode character, the unicode script is very useful !

TL;DR: Spread the word, ♥ Unicode ☺

One cool feature present in zsh is the notion of suffix alias (described in zshbuiltins(1)). Quick example :

$ alias -s pdf=evince
$ filename.pdf

… will open filename.pdf under evince, as if evince filename.pdf had been typed. Handy !

But it is not restricted to files : the command is executed whenever the command line matches a suffix alias. So, for example you can define :

alias -s git='git clone'

… so that everytime you paste a URL ending in git, say git://git.debian.org/git/aptitude/aptitude.git, it will be git-cloned.

In the past, filesystems were sitting on directly on top of partitions. It means that it was very difficult to change their size.

Modern systems (post-1998) can use LVM, which is a layer between filesystems and partitions. One of its advantages is that you can resize logical volumes (a LV is the virtual device node where the filesystem sits) after they have been created.

To resize the / and /home filesystems, it is necessary to change the change the size of both the filesystems and the LVs. But it is not possible to do it in any order: at any time, the filesystem must be smaller than its LV. So, the correct order of operations is:

• shrink home filesystem
• shrink home LV
• expand root LV
• expand root filesystem

Wait a second before you start reaching for your favorite live CD: all these operations can be done online. Actually, the two first ones need /home to be unmounted, so it has to be done in single user mode. Online expansion of the root file system is fairly new (it’s from Linux 3.3, 2012) but it works like a charm.

Manipulating partition and volume sizes are always a bit tricky. Sometimes you have to give sizes in blocks, sometimes in bytes. Sometimes it’s multiples of 1000 and sometimes it’s multiples of 1024. I would not feel comfortable after typing 4 commands with 4 sizes. Fortunately, LVM tools are wonderful and can “talk” to the underlying filesystem (using fsadm). And LVM knows how much space is free, so it can expand a partition to fill completely the disk (or more precisely the volume group).

In a nutshell, this complex operation can be done in two commands (in single user mode):

lvresize -r -L 800G /dev/mapper/machine-home
lvresize -r -l '+100%FREE' /dev/mapper/machine-root

The -r switch enables fsadm. -L indicates the new size in terms of bytes, and -l in terms of LVM units (+100%FREE means: increase by the whole free space, ie fill the volume group).

That was almost too easy!