More terminal (aka CLI) programs to the rescue

So I just set up Alpine for my multiple Gmail accounts with this guide. It works perfectly. (I first tried setting up mutt, but it was a huge pain, and confusing as well.)

Oh, and I also installed mpd and ncmpcpp . I really like ncmpcpp — it’s so easy to learn with the built-in help system. I like having a simple music player client, without all the cover/album art features that most people care about these days. And the memory footprint of mpd + ncmcpp is very, very, very low. Just the way I like it!

Arch Linux + Xmonad

I finally got around to installing Arch on my desktop yesterday. At first I installed XFCE, and then Xmonad, and then I decided to dump XFCE altogether and just use Xmonad for all my computing needs. Xmonad is tricky to configure, so I only have a very basic xmonad.hs file (it’s the template config file found on the Xmonad wiki pages, minus the parts that give me errors on Xmonad 0.8.1).

I think tiling window managers like Xmonad are really the only way to go. I was getting sick of doing ALT+MOUSE2 to resize my windows to make most of my screen real estate on XFCE. I really like how my windows perfectly line up into neat groups. I haven’t even touched any of the great extensions out there for Xmonad yet.

In other news: I started using vimperator. It’s really neat once you spend 1 day with it. The biggest advantage for me: I don’t have to click on History -> Recently closed tabs -> tab to open up a tab I accidentally deleted. All I do instead now is just type ‘u’! And I don’t do CTRL+T, CTRL+K to do my searches — instead it’s now just ‘t searchterm’ or ‘t a packagename’ (where the ‘a’ is a keyword for the Arch Package Repository search engine). Woohoo!

UPDATE January 28, 2010: So it’s been just over 1 year since I’ve used Xmonad on Arch. Some pro’s and cons of using Xmonad:


  • Excellent use case for dual monitors — since windows instantaneously move & maximize between two (or more) monitors, the awkward feeling of seeing a window with fat monitor bezel “dividing” it up never happens. (In other words, a tiling WM makes a monitor’s bezel width irrelevant.)
  • Probably the best way to research something online while working on a problem. You can open up multiple windows and switch between them instantly. Whenever I’m researching an idea (usu. a school research project or a computer programming-related problem) I have multiple Firefox browsers maximized in various workspaces. A tiling WM + multiple workspaces (FYI, I have 22 workspaces — 1 through 0 in the horizontal numeric keys and F1 through F12) is a lot like having an “expandable” desk — if you run out of space in the current one, you just go grab the next empty one and put more stuff there. Marathon, 4, 5+ hour research/programming sessions have not resulted in my need to have more than 10 workspaces (but I still like having 22 of them).
  • You can do away with an omnipresent “status bar” for the clock, network bandwidth useage, CPU usage, etc., and instead have full-screen versions of such monitoring programs run all the time. For example, I have F12 (the 22nd workspace) set to display htop full screen, F11 to iftop and alsamixer, F10 to alpine (mail viewer), F9 to weechat (IRC), and F8 to ncmpcpp. Having many workspaces frees you from using pesky, real-estate cluttering programs like conky to keep track of your system. I don’t use any kind of status bar like dzen or xmobar whatsoever (I just don’t need to).
  • Encourages you to live in the terminal, since there are no desktop icons or menus. In the course of a year I’ve learned some very useful console commands, and it’s made me appreciate more of the GNU in GNU/Linux.
  • The tiling environment is probably the best one for doing computer programming — it’s easy to instantly launch a new terminal right below your current window to test the binary/script you just compiled/wrote.
  • Xmonad has never crashed on me. (It’s come somewhat close to crashing in cases where I tried to run some PC games over WINE, when the game wanted to change to a different full-screen resolution (yuck) than the one already set by (one of my) monitors. But it’s never crashed.) I’ve never experienced my mouse not responding or my Xmonad workspace-switching hotkeys failing on me. It’s never crashed. Ever.


  • In the early days of Xmonad (v. 0.8.1), updates to GHC would sometimes break Xmonad’s configuration files. Xmonad would start and function normally, but changes to the ~/.xmonad/xmonad.hs configuration file would not be recognized by Xmonad. However, this had to do with Arch’s packaging process and the lack of synchronization between Arch’s packages and the Haskell community. I haven’t experienced any significant problems at all since v.0.9.1 came out, so, this is a non-issue.
  • Some windows are naturally designed to “float” (not become maximized and tiled), especially small apps like galculator or agave. Such apps have to be manually configured to float every time in your xmonad.hs config file. Doing so requires that you use the “xprop” command and parse everything manually — a bit annoying each time you do it, but thankfully after 20 or so of these customizations you won’t have to be bothered with this for a good while.
  • To make most out of a tiling WM, you will have to learn to live in the terminal. That means knowing your ~/.zshrc or ~/.bashrc intimately well, and coordinating your shell aliases to work well with Xmonad (e.g., like how I have “of” aliased to “sudo poweroff” — or how I have “usbon” aliased to “sudo mount -w -t vfat -o uid=shinobu,gid=shinobu /dev/sdc1 /mnt/media-flash”). I even had to make a custom ZSH function called univ_open() to satisfy my needs. And because everything in Xmonad is heavily keyboard-shortcut-driven, use of the mouse becomes somewhat annoying. Thus I keep getting annoyed by things that are mouse-centric, like any app, or even galculator to a degree. But even if I could do everything from the keyboard, the problem is that many programs do not allow you to easily change the default key bindings — such as apvlv, mirage, alpine, htop, iftop, alsamixer, rtorrent, etc. You have to learn the different key bindings for all these programs.

Pros or cons depending on whether you are a geek:

  • Since there is no status bar or task tray like GNOME/KDE/etc., that means that you have to figure out how to access very low-level stuff manually. These are things like setting the volume, changing the monitor brightness, sleeping or shutting the computer off, mounting/unmounting USB devices and CD/DVD media. Thus, I have to have Xmonad hotkeys to lower/raise/mute the volume and change the brightness (for my laptops). To turn the computer off, I have “of” bound to “sudo poweroff” and “ofo” bound to “sudo reboot” (I had to learn these console commands online — as they are distro-specific).  Unless you’re a geek like me, you’re going to have a hard time trying to get everything working smoothly. (Another example of something I had to learn online: I have to type “& disown” after typing up a command to start up a GUI, since otherwise my current terminal can’t do anything until the GUI app is exited.) I had to learn commands like ssh, du, df, mount, and umount to get all the information/functionality I’d expect from a regular DE like GNOME. On the other hand, learning these commands have made me work faster and better than ever. So in short, if you’re a geek, a tiling WM helps you learn more essential UNIX-y commands, but if you’re a regular average Joe, a tiling WM is probably not what you want.
  • Customizing Xmonad is somewhat of a challenge at first. It helps if you know some Haskell (only after learning what Haskell lists are did I add 13 more workspaces to the default 9, while still maintaining the mod + key and mod + shift + key functionality to those 13 new windows, in the way the keys are physically lined up on the keyboard (i.e., the ‘0’ key is mapped to workspace 10, not 1)). Unfortunately, there are so many ways that you can slice Xmonad — much like the task of customizing your ~/.vimrc or your ~/.zshrc. If you’re a geek, you’ll enjoy taking small steps to add additional functionality here and there as you go along. But for the average computer user, customizing everything to your liking will be difficult.

Overall though, I am glad I made the switch to a tiling WM. Whenever I find myself sitting in front of a non-tiling WM, I shudder to think of how I used to do all my work (internet-based research, especially, with all those overlapping windows!). I cannot imagine doing any real work without a tiling WM. The only use case I’ve not really done any serious testing with Xmonad is digital content creation — i.e., using GIMP or Blender for digital multimedia work. GIMP is currently awkward to use on Xmonad because of the default floating windows (the 3 that start up by default, plus the many floating dialog boxes). Blender currently does not support multiple monitors, so dual-head setups like mine suffer from it. However, the next GIMP version (2.8) is supposed to support single-window mode. And Blender 2.6 is supposed to support multiple monitors. So things are only going to get better with Xmonad/tiling WMs.

UPDATE June 16, 2010: Here are some more reasons why using a tiling WM (Xmonad in my case) is so great:

  • A better IDE: Because Xmonad is a tiling WM, you make constant use of the keyboard to move around various windows. This means that, suddenly, everything on your workspace becomes “unified” by Xmonad. For example, I remember using Netbeans once when I started programming again a few years ago. I remember the various features of that IDE, such as a file browser, build window, etc. I’ve since switched to Vim for editing any text file, and have realized that with Xmonad, my entire workspace is my IDE! I just create one window for Vim, a terminal for file browsing (any shell, when used intelligently with enough super-concise aliases and shell expansion, beats using a dedicated file browser program) and general-purpose file navigation (with the ack and find commands), another terminal for compiling, another terminal (or two or three) for irb or ghci if I’m working with Ruby or Haskell, a Firefox window for viewing online help (documentation, API, etc.), a PDF-viewer for that interesting computer science article, maybe another window for a calculator (perhaps on a different workspace)… and now, all the various windows serve a distinct purpose. Everything comes together nicely to make to create an evolving IDE. Every time I sit down to do some fun programming projects in my free time, I create only those parts of the IDE that I need. Nothing is wasted. Again, the fact that I can switch between all the various windows (and resize them to emphasize the important ones — Xmonad does this with “layouts” which can be customized) with a single unified set of hotkeys defined by Xmonad’s configuration file makes it all work seamlessly. No more pressing F5 to execute some elongated, intra-(Netbeans, Eclipse, etc.)-compile command — I just move to the compile-dedicated terminal window and press UP for the last build command) and ENTER to do the same thing, but better because nothing separates you from the compiler.
  • Universal access to various “function” keys: The so-called “mod key” that you will come to love and which Xmonad makes extensive use of (you can define multiple mod keys, btw), is always interpreted first by Xmonad, regardless of which workspace you are in or what window you are currently focused on. This is true even for full-screened windows (e.g., mplayer). This means that you can essentially roll your own set of “function” keys to control the volume, screen brightness, and audio player (mpd, in my case). Here’s a snippet of code from my xmonad.hs for this task:

    — ncmpcpp (mpd) controls
    , ((mod4Mask .|. controlMask, xK_o     ), spawn “ncmpcpp toggle”)
    , ((mod4Mask .|. controlMask, xK_h     ), spawn “ncmpcpp stop; ncmpcpp play”) — “reset” current song to beginning
    , ((mod4Mask .|. controlMask, xK_j     ), spawn “ncmpcpp next”)
    , ((mod4Mask .|. controlMask, xK_k     ), spawn “ncmpcpp prev”)
    , ((mod4Mask .|. controlMask, xK_l     ), spawn “ncmpcpp stop”)
    , ((mod4Mask .|. controlMask, xK_semicolon ), spawn “ncmpcpp play”)
    — volume controls
    , ((modm              , xK_backslash ), spawn “amixer -q set Master toggle”)
    , ((modm              , xK_minus     ), spawn “amixer -q set Master 3- unmute”)
    , ((modm              , xK_equal     ), spawn “amixer -q set Master 3+ unmute”)
    — screen brightness (call the script “~/syscfg/shellscripts/sys/”, which is symlinked to /usr/bin/brightness to toggle screen brightness — entry for this in “sudo visudo” allows us to do it as sudo w/o password prompt)
    , ((modm     .|. shiftMask, xK_backslash ), spawn “sudo brightness”) — toggle brightness (100 or 0)

    Since my Xmonad config is spread out across all my personal systems, I have essentially created “unified” hotkeys. Now, the fact that I use different keyboards with different keys, different multimedia keys, etc. does not matter any more, as my Xmonad config file ensures that, at least for mpd, volume, and screen brightness, I can always rely on the same hotkeys to manipulate them. This is a godsend for those pesky multimedia keys on laptops which are usually quirky and don’t always work (and worst of all, are located in different places on different laptop models, if at all). Notice that all of the above commands to change mpd state, volume, and brightness do not produce any screen noise; everything is done silently so that you can focus on what’s important (the movie playing full-screen, the article you’re reading, the code you’re reviewing, and so on). You can see how I’ve mapped the ncmpcpp commands close to the “home row” of keys for extra convenience. All of this is made possible by Xmonad’s straightforward, no-frills keybindings (good luck syncing your keybindings from XFCE/GNOME/KDE/any-other-bloated-DE across your systems). (Btw, the script is a custom zsh script that I’ve written myself — you will find it in my post here.)

Update April 19, 2011: I use pentadactyl instead of vimperator now, as I noted a while ago in this post. Anyway, I’m still using Xmonad! Since learning Haskell earlier this year, I’ve managed to customize my configuration file quite a bit. If you know Haskell, then choosing Xmonad is a no-brainer; the xmonad.hs configuration file is a Haskell source file that is used as a top-level file which pulls in all the necessary Xmonad dependencies to generate the xmonad executable! This means that you can do pretty much anything you want with Xmonad. The cool thing about customizing xmonad.hs is that, even if it gets very complex, the generated xmonad executable will still be rock-solid (unless you shoot yourself in the foot doing stupid things, which is very hard to do in Haskell). This is in sharp contrast to other programs where extensive customization generally leads to less stability. Oh, and Xmonad still hasn’t crashed on me since I started using it.

How to quickly make a (sorted) playlist for mplayer

See my update on July 10, 2010, below (making use of the neat “-iregex” option)!

Mplayer uses a simple kind of playlist: a text file with the path and name of each file to be played. The path to the new file is relative to the location of the playlist file itself. So, you can do:

find -maxdepth 1 -type f -name \*.\* | sort > playlist

This will find all files in the current directory that have a “.” character in it, sort them, and put their paths into playlist (a text file). We have to use the “-type f” argument because we want files, not directories. If you only want flac files, then you can use \*.flac instead. If you have files named “FLAC” as well as “flac”, you can use the “-iname” option to match case-insensitively. If you want to search deeper down directory levels, just increase the maxdepth value, or leave out the maxdepth parameter altogether to search recursively.

But let’s say your music directory is a bit messy with different filetypes. You can find multiple filetypes by just appending “-o -[i]name expression“, like this:

find -maxdepth 1 -type f -iname \*.flac -o -iname \*.ogg -o -iname \*.wav | sort > playlist

This will find all flac, ogg, and wav files case-insensitively in the current directory. You might even want to make a shell alias for this command (in your ~/.zshrc, ~/.bashrc, etc.), so that you don’t forget:

alias fa='find -maxdepth 1 -type f -iname \*.mp3 -o -iname \*.flac -o -iname \*.ogg -o -iname \*.wav -o -iname \*.aac | sort > playlist'

Now you can type fa (find audio) to generate a playlist for (most, if not all) audio files in the current directory. The only risk here is that playlist already exists, but that likelihood is small enough to ignore. This is because the “>” operator replaces whatever content that was inside the “playlist” file with the output of the previous command. If you just wanted to append the results to an existing playlist file, you could just use “>>” instead of “>”.

To play the playlist, just do:

mplayer -playlist playlist

…where “playlist” is the file with all the songs in it. Be sure to include the full path to the playlist if you are currently not inside the same directory. To make the entire playlist loop forever, type:

mplayer -playlist playlist -loop 0

and it will loop the entire playlist forever. Unfortunately, putting the “loop=0” info in my ~/.mplayer/config file makes mplayer read that paramter first, and thus, only repeat the first file in my playlist forever. There seems to be no workaroud to this, except manually appending the loop paramter after the playlist parameter, as shown above.

More info here.

UPDATE November 12, 2009: I discovered a simple hack around the above mentioned problem about trying to loop the entire playlist. The solution is to remove the “loop=0” line from your ~/.mplayer/config, and instead make use of shell aliases. I use zsh, and this is what I have in my ~/.zshrc (the second alias is the key):

alias m='mplayer -loop 0'
alias mp='mplayer -loop 0 -playlist'

Now, to play any single file infinitely, simply use “m [file]”. To infinitely loop an entire playlist, simply do “mp “. You can use the “>” and “<” hotkeys to move around the playlist.

UPDATE December 31, 2009: Silently updated the post to include the sort command. Without piping things to sort, the playlist would be somewhat random in order (find probably neglects sorting in exchange for faster results). Also added some more advanced techniques.

UPDATE July 17, 2010: Instead of typing a bunch of “-o -iname”  flags, a simpler way is to just use a combined regular expression:

find -maxdepth 1 -type f -iregex ".*\.\(aac\|flac\|mp3\|ogg\|wav\)$" | sort > playlist

Arch Linux: First Impressions

NOTE: Check out the newer review, here!

So now that I’ve been using Arch Linux on my laptop for 2-3 weeks now, it is time for a review. Since I’ve already written (albeit a bit  indirectly) about the advantages of Linux (any distro) over Microsoft Windows, I will not repeat myself as to those points. I will first discuss why I decided to ditch Xubuntu, and then talk about why I think I made the right choice.

Why I Switched to Arch Linux

These were the most compelling reasons to make the switch:

  1. Faster boot times on my aging laptop.
  2. Freeing myself from the endless cycle of upgrading from one point release to another (e.g., getting rid of “Hardy” and installing “Ibex,” and so on).
  3. The desire to stay ultra-modern as far as software is concerned — i.e., getting the latest stable versions of software with ease.
  4. Freeing my system of any unnecessary packages (aka “bloat”) / keeping my system as simple as possible.

As for #1, I think this reason turned out to be the most misleading one. I don’t notice any significant gains in bootup times. But, it’s not like I can expect a whole lot from this Dell Latituded D505. As for #2, this is a huge bonus. As you may well know, Arch is famous for its “rolling release” system (like Gentoo). I.e., once you install it, and update it using the package manager (known as pacman), you are up-to-date with the latest software. I also appreciate how quickly the Arch maintainers update their packages to the latest versions, to make this all work. Reason #3 thus fits in with #2. As for #4, I can feel that there’s less bloat — since I installed almost everything manually, including XFCE, after the Arch installation finished!

Why the Switch Was Worth It

Yes, I have no regrets. The installation itself took around 2 days (one evening to get through the installation process, and another day to install XFCE and to customize most things back to how things were), and I learned a lot about Linux just by going through this process.

I don’t fear losing the direct applicability of the mountains of Ubuntu forum posts should I get in trouble or if something breaks. I’ve noticed that generally, the Arch community is composed of people who’ve used Linux for quite some time, and they are very, very active. Their community spirit is very impressive, and all the more helpful, since there are fewer first-time Linux users. The Arch Wiki pages are particularly well-documented, although a bit disorganized at times.

I also like how I understand most of my core files, like my xorg.conf and GRUB’s menu.lst files, since they do not come pre-installed with a bunch of comments and options that I didn’t put there. Both of these files are shorter and cleaner than before.

I will probably install Arch64 (the 64-bit version of Arch) on my desktop later this spring, or summer.