Refining Linux

A new appearance

Yay, Refining Linux got a face-lift!

This blog has now been up for a good one and a half year and nothing has changed much since it started. Now it's time to give it a redesign (if you ask me, this was long overdue). While the main appearance stays the same, the details have changed significantly. Let me walk you through the new goodies.

Responsive design

The most awesome feature first: the whole design is now completely responsive and can be viewed at any size. The old desktop-only design has been replaced by a brand-new flexible design for any kind of device, be it a small smartphone, a bigger tablet or a giant 30" display. Refining Linux has it all.

If you like, you can test this. Just resize your browser window and see how great the new design adapts to the new width. The minimum size I consider looking well is about 240 pixels, but there is no upper limit. It just might start looking a bit ridiculous if you project a tiny page onto your 5k display wall.

Nicer typography

Although Georgia and Verdana are not the worst choices I made in my life, they don't look very pretty. They're old veterans of the web-safe fonts battalion and have gotten a bit long in the tooth. Nothing against these fonts in general, but it was time for something different. I mean, we live in the age of web fonts, don't we?

The new choices are Clarendon Paint and Aller, two fresh fonts for the new look and feel of Refining Linux. I like both and think they support the overall painted appearance.

Improved Header

Not only the body has been refurbished, also the header has been pimped. It was actually the last thing I took care of, but that doesn't mean it's not important. It is. Our little painting Tux has become a bit more lifelike, the background painting a bit more realistic. I also took care of the main menu. It got some more detail, less straight edges and some subtle CSS gradients for the hover effect.

In general I haven't modified much in the header, but again, the details have changed. It's perfectly possible that some things in the header might still be tweaked from time to time, but for now I leave it as that.

Redesigned comments section

The comments section has especially been taken care of. It looks very different now and much better in my opinion. The speech bubbles make a lot more sense this way and the overall look is much cleaner and more pleasing to the eye. I hope you like it as well.

The amount of indentation has grown a bit with the redesign, so I have limited the maximum number of indents to four (plus the root level, i.e. five). Comments already being submitted at a higher nesting level retain their position in the database but their display is linearized at the fifth level.

Also the comments form (and the contact form as well) has been redesigned slightly. It also looks a lot cleaner now and I put in some nice HTML5 form validation features there (more on that in a second).

Better syntax highlighting

The syntax highlighting has much been improved. Instead of SH_JS I'm now using Highlight.js which gives me way more accurate highlighting and particularly more control. Especially for the last Advent series I created a special ZSH highlighting scheme. I couldn't really do that in SH_JS without having to learn GNU Source Highlight (I'm too lazy for that).

The new color scheme for the syntax highlighting is based on Ethan Schoonover's famous Solarized theme. Personally I don't like Solarized too much for my editor (the colors are too muted to my taste), but for the website, I believe, the bright theme is great.

Yes, there are still some glitches here and there in the highlighting, but I guess I will be able to fix them over time. The highlighting as it is now is already tremendously better than it was ever before.

HTML5 rewrite

The whole page has been rewritten in HTML5. This wasn't necessary, but I did it in the process of making the whole thing responsive. It now uses semantic HTML5 markup and of course also goodies like HTML5 input type validation for the comments form, a new Canvas tag cloud (replacing the old and ugly Flash tag cloud) and much more.

The tag cloud, by the way, should be completely accessible as it is based on a normal list of links. Users with very small screens, touch based devices or disabled JavaScript will get that version instead. Also screen readers should be able to access the fallback version.

Better legacy IE support

Although I don't care much, a nice side-effect of the responsive design and its “mobile-first” approach is that the support for IE6, 7 and 8 is much better now. IE9 renders everything fine and just lacks support of some minor things such as gradients without SVG. IE8 and older, however, does horrible things to the layout, especially with the new unknown HTML5 elements which I can only get to work with JavaScript. But with the mobile fallback and a few minor fixes I got a more or less decent but at least working version for old IEs. With JavaScript enabled it looks a little less horrible, with JavaScript turned off a little more. But overall it's all working and the two IE users I have will get a very rough but usable basic version of the website (actually, it's a bit more. I have about 7-8% of IE users here of which about a quarter uses IE 9 or above. In December the IE rate was even as low as 5.7%).

Enjoy!

I hope you enjoy the redesign as much as I do. If you like, you can help me a little by doing some browser testing. Although I have tested this on Linux and Windows in many browsers, there might still be some glitches here and there. If you find some, please let me know.

Have fun!

SOPA blackout

Tomorrow this blog will be blacked out for 12 hours starting at 1400 CET (1300 UTC or 8 AM EST).

With this initiative Refining Linux is following the protests against the Stop Online Piracy Act (SOPA) and the PROTECT IP Act (PIPA) proposed by US legislators and the media industry. Many huge Internet companies and organizations such as Reddit and Wikipedia participate in these protests. Also companies such as Google, Amazon, Facebook and of course non-profit organizations such as Mozilla and many smaller groups support the protests against SOPA and PIPA.

Why is this so important?

These two bills have the goal to give law enforcement agencies more power to fight against “rogue websites” and copyright infringements in a way that highly endangers free speech and open communication infrastructure. As supporters of open source initiatives and democratic processes we have to intervene and prevent these bills from becoming applicable law.

Fortunately at least the DNS filtering parts of both these bills have been suspended for now due to massive protest from all over the country and around the world, but many evenly dangerous parts persists and the idea behind the whole proposed law isn't dead at all. In fact, it is very much alive and similar attempts are being made behind closed doors in other countries as well. One example is the Anti-Counterfeiting Trade Agreement (ACTA) which is currently negotiated by many countries in the European Union.

Therefore this is not just a matter of US citizens, it is a matter of people around the world.

Why are so many big companies against SOPA and PIPA?

The simple question is: because the Internet is their business. Other than the entertainment industry, which mainly supports SOPA, these companies depend on the Internet. Should these bills become law, they could be held responsible for any third party content appearing on their websites. That means in an extreme case a single search result pointing to an illegal website could be reason enough to sanction Google. The same applies to any other website with user contributed content such as Wikipedia, Reddit, Facebook, any online community, even your private web forum. All posts made to these website had to be checked and approved manually before they appear publicly. That is impossible to do and a massive restraint of free speech and open communication.

The same applies to ACTA and any similar proposed agreement that abuses legal forces to destroy the freedom of people in the name of fighting online delicts.

You should participate as well

Refining Linux protests for a free Internet and so should you. As Sue Gardener wrote in the Wikimedia's announcement to black out Wikipedia (which I linked above):

“The reality is that we don’t think SOPA is going away, and PIPA is still quite active. Moreover, SOPA and PIPA are just indicators of a much broader problem. All around the world, we're seeing the development of legislation intended to fight online piracy, and regulate the Internet in other ways, that hurt online freedoms. Our concern extends beyond SOPA and PIPA: they are just part of the problem. We want the Internet to remain free and open, everywhere, for everyone.”

This is absolutely true. Even if you're not a US citizen (like me) this affects you. Bills like SOPA, PIPA or ACTA must not pass legislation. They destroy open communication around the world and change the Internet in a way we really don't want it to be.

So please sign the petitions against SOPA or ACTA or call your representatives.

Thank you
Janek

Update 01/19/2012 0100 UTC:

Refining Linux is back. Thanks to all who showed their support.

ZSH Gem #24: ZSH frameworks

I have shown you many things about ZSH throughout this series, but there is much more you can do with it than I could cover here. And of course there is also much more to configure, many more options I couldn't tell you about, many more tips and tricks, tweaks and optimizations.

Generally, it's a long way to go before you have your shell set up as you like. Especially ZSH needs a lot of configuration before it becomes very user-friendly. You can do all this configuration by hand or you can use a framework for that. Yes, there are frameworks for ZSH (and for Bash as well, in case you didn't know) and as a completion of this Advent series I'll show you two of them.

oh-my-zsh

Probably the most advanced and mighty ZSH framework is oh-my-zsh. oh-my-zsh provides lots of extra features, special plugins with additional functions and completion definitions for certain command line tools and many, many themes for modifying the appearance of your shell, particularly the prompt.

To use oh-my-zsh, download it to a directory of your choice (e.g. ~/.oh-my-zsh) and load it from within your .zshrc:

# Path to your oh-my-zsh installation (the framework won't work without this setting)
ZSH=$HOME/.oh-my-zsh

# Load oh-my-zsh
source $ZSH/oh-my-zsh.sh

That's basically it. You've successfully loaded the framework. But until now it doesn't do much except changing the default prompt to something a bit more meaningful and configuring some basic stuff such as enabling ls colors. But you can customize the framework. For example to disable ls colors again, write the following in your .zshrc before the line where the framework is loaded:

DISABLE_LS_COLORS="true"

To set another theme modify the parameter $ZSH_THEME:

ZSH_THEME="candy"

Now when you re-source your current shell instance you have the candy theme activated. For a full list of available themes have a look at the themes folder inside your oh-my-zsh folder. An even better overview can be found in the oh-my-zsh wiki on GitHub.

Next let's come to the plugins. By default, no plugins are loaded, but that can be changed. Similar to ZSH's $fpath array, oh-my-zsh has a special $plugins array which contains all the names of all the plugins to load when initializing the framework. For instance:

plugins=(git github perl svn)

for loading the plugins git, github, perl and svn which will provide extra functions and completion features for the corresponding applications. For instance, the git plugins adds many advanced completion features for working with Git repositories and the shell function current_branch as a shorthand for displaying the branch you're currently working on without any additional meta data or formatting stuff.

oh-my-zsh is pretty mighty and you can have a lot of fun with it. Just be aware, that even though ZSH provides an autoloading mechanism for functions, loading too many plugins can slow down your shell. It can be very annoying when you always have to wait 10 seconds after opening a new shell instance.

If you're not quite sure how to start with oh-my-zsh, have a look at the example .zshrc in the templates folder.

zshuery

zshuery is another framework for ZSH which is much smaller. It's more something like a micro-framework. The name is derived from jQuery and the idea behind it is to provide a simple and flexible yet fast framework. zshuery doesn't have lots of plugins. It's just one single file which provides some extra functionality and does the basic ZSH configuration for you. That's it. Compared to oh-my-zsh, zshuery is a stub but that's why I like this framework and prefer it over the more powerful oh-my-zsh. It's just what it wants to be: a simple framework which makes working on the shell easier without blowing you away with feature you probably never need. With some extra configuration in my .zshrc this framework is exactly what I need.

But first things first. Loading zshuery is pretty much straightforward. Just download the framework to an arbitrary folder and reference it in your .zshrc:

# Load zshuery
source ${HOME}/.zshuery/zshuery.sh

That loads the framework. Now to let zshuery set some default options, aliases and autocorrection for you, call the following functions:

load_defaults
load_aliases
load_correction

I told you that zshuery doesn't come with plugins and that is true. However, it provides an easy way to load additional completion functions from the zsh-completions Git repository. These are autocompletion functions which might not yet be in the official ZSH release. To include them, clone the repository (preferably to a directory somwhere inside your zshuery folder) and call the following zshuery function:

load_completion ${HOME}/.zshuery/completion

(provided the path to your copy of the zsh-completion repository is ~/.zshuery/completion)

And finally my Christmas gift for you…

zshuery is a great framework for pimping your Z Shell without overloading it. And because it's my favorite ZSH framework and because Christmas is just around the corner, I give you a commented version of my .zshrc in which I use this framework with some slight modifications:

# Load zshuery
source ${HOME}/.zshuery/zshuery.sh
load_defaults
load_aliases
load_correction

# Colorize ls output
alias ls="ls --color=auto"

# Redefine ls colors and load completion definitions
export LS_COLORS="no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:"
load_completion ${HOME}/.zshuery/completion

# Modify key bindings to make certain keys such as DEL, HOME, END, PAGE UP and PAGE DOWN work
eval "$(sed -n 's/^/bindkey /; s/: / /p' /etc/inputrc)" > /dev/null
bindkey "\e[5~" beginning-of-history    # Page Up
bindkey "\e[6~" end-of-history          # Page Down

# Colorize STDERR (enable if needed, might cause issues with password prompts or escape sequences)
#exec 2>>(while read line; do; print '\e[91m'${(q)line}'\e[0m' > /dev/tty; print -n $'\0'; done)

# Enable menu select
zstyle ':completion:*' menu select

# Enable tree view for kill completion
zstyle ':completion:*:*:kill:*:processes' command 'ps --forest -e -o pid,user,tty,cmd'

# Modify zshuery correction prompt
SPROMPT="Correct $fg[red]%R$reset_color to $fg[green]%r?$reset_color (Yes, No, Abort, Edit) "

# Load fancy prompt (works on Gentoo Linux only)
autoload -U promptinit
promptinit
prompt gentoo

# Non-Gentoo users might configure their prompt manually.
# The default Gentoo prompt from above would look like this:
#PROMPT="%B%{$fg[green]%}%n@%m%k%{$reset_color%} %B%{$fg[blue]%}%1~ %# %b%f%k%{$reset_color%}"

# Set options
setopt complete_in_word
setopt path_dirs

# Load modules
zmodload zsh/regex
zmodload zsh/pcre

# Update terminal CWD once and then on every CWD change
update_terminal_cwd
function chpwd() {
        update_terminal_cwd
}

# Extend $PATH
PATH="${HOME}/.local/bin:${HOME}/.local/opt/bin:${PATH}"

Use it for whatever purpose you want. Modify it, extended it, republish it, whatever comes to your mind. You can also use it together with oh-my-zsh or no framework at all if you like that better. Just alter the lines where the framework is loaded or used.

ZSH Gem #23: Working with extended regular expressions

There are two ZSH modules which allow you to easily work with POSIX extended regular expressions (POSIX ERE) or with Perl compatible regular expressions (PCRE) which are even more advanced than POSIX ERE. These two modules are zsh/regex and zsh/pcre. You can use either one of them or both at the same time. That's entirely up to you. I'll show you both.

First let me illustrate zsh/regex a bit which is the simpler one of both. zsh/regex provides, once loaded, the new conditional expression -regex-match which can be used in combination with the [[ command (e.g. in if conditions or loops):

# Load module
zmodload zsh/regex

# Execute POSIX ERE
[[ "foobar_123" -regex-match "^([a-zA-Z0-9]+)_([0-9]+)$" ]] && echo match || echo no match

The condition returns true if the expressions matches, otherwise false. If there are any matches, the whole matching part is stored in the $MATCH parameter and if there are any substrings in parentheses, these parts will be available in the array $match (here in our example you'd have an array with two elements containing foobar and 123).

Now that I've shown you zsh/regex let's come to the more complex zsh/pcre. zsh/pcre also provides a new conditional expression called -pcre-match which works about the same as -regex-match except that it accepts Perl compatible regular expressions. So we could rewrite our example from above as follows:

# Load module
zmodload zsh/pcre

# Execute PCRE
[[ "foobar_123" -pcre-match "^(\w+)_(\d+)$" ]] && echo match || echo no match

That's a little less to write. But zsh/pcre also provides a few new commands besides the conditional expression -pcre-match. The most important ones to know are pcre_compile and pcre_match. With the first one you compile a regular expression from a string and with the second one you use this compiled regular expression on other strings. That means you always need to use both in combination.

Both commands provide several flag parameters. The most important ones for pcre_compile are -m which will match multi-line patterns, -s which makes the dot pattern (.) match whitespace as well and -i which makes the pattern case-insensitive.

The most important flags for pcre_match are -v and -a which let you set different names for the match variable containing the whole matching part and the match array containing all the substrings from enclosing parentheses (which are again $MATCH and $match by default).

Our example from above with pcre_compile and pcre_match would look like this:

pcre_compile "^(\w+)_(\d+)$"
pcre_match "foobar_123" && echo match || echo no match

Sometimes it may be more to write, but it also gives you some more flexibility due to the arguments both commands can take. For example, the following simple case-insensitive regular expression

pcre_compile -i "^foobar\s+\d+$"
pcre_match "fOoBaR   123" && echo match || echo no match

would need such a monster expression if just performed with -pcre-match:

[[ "fOoBaR   123" -pcre-match "^[fF][oO]{2}[bB][aA][rR]\s+\d+$" ]] && echo match || echo no match

In this case the second variant is not just more to type (yes, that's true, count the characters), the first one is also much easier to read and less error-prone so I'd prefer that one.

Whichever variant you take and whether you prefer POSIX regular expressions or PCRE always depends on the situation. But all of them give you the full power of regular expressions. So use them!

ZSH Gem #22: Accessing and editing files with mapfile

Working on the shell is often working with files and sometimes you need to read or edit their contents. Normally you'd do that with the command line editor of your choice (e.g. nano, vi, vim or emacs), but sometimes you need to write the output of a command or a pipe to a file or feed programs with contents from the hard disk. That's usually done by using the input and output redirection operators, but ZSH gives you one more tool which can sometimes make things easier. This module is called mapfile.

Since mapfile is a ZSH module you need to enable it before you can use it:

zmodload zsh/mapfile

Once the module is loaded, you get the magic associative array $mapfile which gives you direct access to any file when you specify its name as the name of the array key. For example, to echo the contents of the file examplefile run

echo $mapfile[examplefile]

You can also write to files by assigning values to an entry of the array. The value will then be written to disk. If the file does not exist yet, it will be created. To write the string Hello World to our file, run

$mapfile[examplefile]="Hello World"

That's the basics and about everything mapfile can do. How do we make use of it? mapfile can sometimes be a nice thing when you need to work with contents of a file in a very simple way. By using mapfile you can avoid piping the contents through chains of commands or doing stuff like this:

filecontents=$(cat file)

mapfile also enables you to do some basic filtering and editing directly when accessing the file by using ZSH's parameter expansion operators. For example if you need the contents of a file converted to all lowercase, the only thing you need to do do is

echo ${(L)mapfile[file]}

or if you need the contents of a file or a fallback value in case the file doesn't exist, mapfile should be the easiest way to go:

echo ${mapfile[file]:-Fallback value}

or if you need to do some initial search and replace:

echo ${mapfile[file]//search/replace}

Of course, you can also write the edited contents back to disk:

mapfile[file]=${mapfile[file]//search/replace}

No big deal. Another thing you could do is to get the length of a textfile in characters (i.e. bytes):

echo ${#mapfile[file]}

Whatever you want! You can also use mapfile in combination with vared to let the user edit files interactively:

vared mapfile[file]

Of course, you could also open some more advanced editor such as vim, but at least as a fallback, mapfile in combination with vared becomes a valuable tool because no external program is required.

You see, under some circumstances, mapfile can really save your neck. But you should also be aware, that it may also consume a lot of memory, particularly with large files. So use it with caution.

ZSH Gem #21: Completion of abbreviated filenames

Yesterday I told you about how to use the full potential of the cd command. Today I want to go one step further and show you how you can reduce the number of characters to type even more.

As I've already shown you several times throughout this series, ZSH is very capable of completing things when hitting the TAB key. Today I'll show you two more features concerning completion of abbreviated or incomplete pathnames.

The first feature I want to present you with enables you to complete incomplete parts of a filename. It can be activated with the option COMPLETE_IN_WORD. You can set the option as usual with setopt (as always, make sure the completion engine is loaded):

autoload -U compinit && compinit
setopt complete_in_word

So now that it's enabled, how do we use this feature? Well, it's very simple. Imagine, you want to switch to the directory /home/johndoe. You type:

% cd /hme/john

But before you finish the word johndoe you realize that you didn't get the first part of the pathname right and forgot the o in home (maybe your keyboard is a bit older and some keys have become a little stiff). You could now hit the arrow keys to go back, fill in the missing o, jump back again to the end (either with the arrow keys or with the END key) and then write the rest of the name (or use the normal TAB completion). That's a relatively long procedure. But with COMPLETE_IN_WORD you can save some time. Just use the arrow keys to go back until the cursor is on the m right after the missing character and then hit TAB. ZSH will automatically complete hme to home and also fill in the rest of the name and set your cursor back to the end of it. So you end up with /home/johndoe/ and the cursor after the last slash, ready to type in more words.

Quick and easy! Can't we always use something like this to save some characters? Of course we can and we don't even need COMPLETE_IN_WORD for it. We just need to enable the completion engine (see above). Once this is done, we can use abbreviated path names where we want. For example to switch to /home/johndoe/Documents write

cd /ho/jo/Do<TAB>

The TAB key completes the path and the only thing left to do is to press enter to execute the cd command. As long as you specify the first (!) few characters of each directory level, ZSH will be able to complete the whole path.

But what does ZSH do when there is more than one possible match? First of all, ZSH evaluates the whole path which makes ambiguous paths very unlikely. For instance, if you enter /ho/jo/Images<TAB> and there is a directory /home/johndoe and a directory /home/johnwayne but no directory /home/johnwayne/Images* then ZSH will automatically complete to /home/johndoe/Images. If there is still more than one possibility, ZSH will complete up to the first ambiguous match and place the cursor at its position. Just enter a few more characters there and hit TAB again. ZSH will then continue the completion with the additional information it just got from you.

In my opinion, these two filename completion features make switching directories very fast and convenient. If you haven't already tried them out, now is the time.

ZSH Gem #20: Changing directories the pro's way

I guess, the cd command is the most often neglected command. Nobody really cares about what this command can do, but in fact, ZSH has added some magic to it, which makes it worth a more thorough look.

I told you about AUTO_CD before, a shorthand syntax for the cd command. But that's not the only thing ZSH has done to cd.

The first exciting feature I want to tell you about is changing directories by replacing parts of the current path name. That sounds abstract, but let me explain. It's actually quite simple. Imagine, you are in your home directory /home/johndoe and you need to change to the home directory /home/janedoe. You could easily do that with

cd ../janedoe

or with AUTO_CD enabled

../janedoe

That's already nice and short, but have a look at this:

cd john jane

If you like, you could even omit the j as it's the same in both names and run just

cd ohn ane

What the command does is obvious: it replaces the first occurrence of the first string in the current path name with the second string. The string can appear anywhere in the path name. As long as the newly generated path is a valid directory, it will work. If a replacement is ambiguous (e.g. if there is also a home directory /home/janetdoe where cd john jane could either switch to Jane's or Janet's home directory), the match which comes first in the alphabet is taken.

cd johndoe/john janedoe/jane

switches from /home/johndoe/john to /home/janedoe/jane and for instance

cd usr usr/local

can change from something like /usr/share/applications to /usr/local/share/applications without typing any unnecessary characters.

That is the first cd pro feature I want to show you. The second one is working with the directory stack. Just like Bash, ZSH has a so called directory stack. That's a list of directories you can work with. The top-most entry is always the current working directory. You can view the current directory stack with

dirs -v

To work with the directory stack, you can use pushd DIR to change to the directory DIR and place it on top of the stack or popd to remove the top-most entry from the stack and automatically change to it. popd can also take an argument +n or -n where n is a number defining a specific entry counting from the top or the bottom.

That's all the same Bash as in ZSH and to be honest: I've never worked with it because using popd and pushd is quite cumbersome and I'm faster without (defining aliases for frequently used directories is more convenient). As I told you, the top-most entry is always the current working directory, but normally when you cd to another directory, the new working directory isn't put on top of the stack. Instead it replaces the last entry for the CWD. To really add directories to the stack you have to do it explicitly with pushd.

However, in ZSH you can work with the directory stack directly with cd. If the option AUTO_PUSHD is set, the current working directory is automatically added permanently to the stack. That means, the stack contains the whole history of all the directories you've been in during this session. To prove that, make sure AUTO_PUSHD is set, navigate through some directories as you'd normally do and then enter dirs -v. You should see all the directories you just skipped through in the stack (directories you entered twice are not saved again but moved to the top of the stack).

Now that you have the stack, you can use cd to navigate between its entries. Use the normal popd argument syntax for it:

cd +4

cd's to the fourth entry from the top.

cd -2

goes to the second entry from the bottom. No need for manual pushd or popd calls. Just use cd {+|-}n to switch between the entries and let ZSH handle the stack by itself. Don't bother about that anymore.

Read more about cd and directory stacks:

ZSH Gem #19: Global aliases

I guess each shell implementation knows something like aliases. With aliases you can give commands different names which might be more convenient for you. That's nothing new, but ZSH has a feature called global aliases.

An example of a normal alias would be to create a shorter name for the rename command:

alias rn="rename"

Now you are able to call the rename command via the short name rn. You can also redefine commands with frequently used options:

alias ls --color=auto

But that's nothing you couldn't do in Bash as well. But let's come to the so called global aliases. To define a global alias you need to option -g of the alias command. Global aliases are not limited to command names and can be used as a replacement of (nearly) any part of the syntax. For example if you often pipe things to grep and you don't always want to write | grep -i you can define an alias for that:

alias -g gp="| grep -i"

From now on you only have to write gp instead of | grep -i. For example:

echo 'Foo bar' gp foo

and you get all lines containing foo.

As I said before: with global aliases you can give nearly everything on the shell an alias name. Even globbing patterns:

alias -g asterisk="*"
ls asterisk

That's particularly useful if you have a very complex globbing pattern that you need more than once. Just define an alias name for that. To demonstrate that even better, let's use our monster globbing pattern from the extended globbing article and define an alias name for it:

alias -g monsterglob="**/([^A-Z[:digit:]])##(#q.x^X^u1002Lm+30mM-1)"
ls -l monsterglob

I guess you see how extremely convenient and powerful this is and any why you should always use the -U parameter when auto loading functions. You can even define aliases for variables:

alias -g p='$PATH'
echo p

Okay, that doesn't look very expedient, but imagine what you could do when combining that with other expressions such as parameter expansion:

alias -g nlpath='${PATH//:/
}'

That defines an alias which expands to a newline-separated list of all entries in $PATH. In Bash you could only define such an alias together with a command. Such a command would look like this:

alias nlpath='echo -e ${PATH//:/"\n"}'

The advantage of the ZSH alias is obvious: you can use the alias anywhere where you could use a variable. The Bash alias, however, always needs to be piped to STDIN of another command in order to do further processing because it is an alias for a command, not an alias for some arbitrary part of the syntax.

Besides extended globbing and all the other completion and expansion features, global aliases are the reason why I love ZSH and I hope, I could enthuse you as well. If not, then hopefully with one of the following articles before this series is over.

ZSH Gem #18: Regexp search and replace on parameters

In ZSH you can easily perform regexp search and replace operations on shell parameters. The only function you need for this is regexp-replace.

Regexp search and replace can be very useful when writing shell scripts which need to process input data, directory names, process trees etc. You assign the string which you need to work on to a parameter and then run the replace function on it. But before you can do anything, you need to load the function first:

autoload -U regexp-replace

The syntax of regexp-replace is as follows:

regexp-replace VARNAME REGEXP REPLACE

where VARNAME is the name of the variable, REGEXP the regular expression and REPLACE the replace string.

As an example of how to use regexp-replace let us replace all occurrences of /foo/bar in the $PATH variable. So let's add that first of all:

PATH="$PATH:/foo/bar"
echo $PATH

There we have it. Now let us remove that entry again:

regexp-replace PATH ':/foo/bar' ''

That will replace our newly added string with an empty string. Of course this was a very basic pattern. But we can use the full POSIX extended regexp syntax and if we enable the option RE_MATCH_PCRE

setopt re_match_pcre

we can even use full Perl compatible regular expressions (provided ZSH was built with PCRE support). Let's do that and replace all entries starting with /usr/ with foo:

regexp-replace PATH '(^|:)/usr/[^:]*' ':foo'

Unfortunately there is no direct way to use back references for each parenthesis expression in the replace pattern, but there are at least some special variables: $MATCH contains the matched portion, $1 contains the variable name and $2 contains the pattern. For instance to append /subdir to the paths starting with /usr instead of replacing the whole thing, we could write

regexp-replace PATH '(^|:)/usr/[^:]*' '$MATCH/subdir'

Mind the single quotes! $MATCH is not an actual shell parameter but rather a placeholder which is replaced by the regexp-replace function. If you would use double quotes or even no quotes, you'd get an empty string (except $MATCH already has some value assigned to it, but normally that's not what you want anyways). The same applies to $1 and $2.

regexp-replace is a nice addition to ZSH's parameter expansion patterns. It's easy to use and in most cases more than sufficient.

ZSH Gem #17: Changing directories with auto_cd

This is probably the shortest tip of this series. I only want to show you a ZSH-specific shorthand for changing directories.

The ZSH option AUTO_CD makes it possible to change directories by just writing their names without using cd. This might be interesting for those of you who always want to type as few characters as possible. If you are one of those, just activate the option:

setopt auto_cd

You will still be able to use the normal cd syntax, but now you can also switch the directories by writing the directory name only. For instance, to change to the parent directory, just write .., hit enter and there you go. To go into the subdirectory bar inside the subdirectory foo, write foo/bar. Pretty easy. it's the same as cd just without cd.

Personally, I use this syntax rarely, but that's not because I don't find it useful. It's just that I'm used to write cd and I often have already typed these two characters before I remember that I wanted to use the shorter syntax. But I guess, some of you might do better and speed their workflow up a little by using this shorthand directory switching syntax extensively.