However, after spending a day on it, I felt the need to get started with Linux. However, Vista isn’t that bad when you have a quad-core processor and 8 gigs of RAM. My problem is as follows:

• I need to be able to play games
• I want my games to run well
• I need a Linux environment
• Ideally, I’d run Linux natively

This leaves me with the obvious option of dual-booting, but I’d really rather not. I find it so… traumatic, if you will, to have to reboot my computer every time I want to change what I’m doing. And since I tend to fire up Team Fortress 2 rather frequently, I’m afraid I’d sit in Vista most of the time because of it, and only go to Linux when I need to. And that’s exactly the opposite of what I’d want. So what to do?

I don’t know what I’m going to do. In addition, while I’ve always had fun with Gentoo, the new installation I started has been proving challenging. The basic system was easy, but the framebuffered console and a desktop (with Compiz-Fusion) has proven difficult. This is in large part, I believe, because of the now-scattered documentation due to the data loss of our beloved Gentoo Wiki. And then I pop in an… an… Ubuntu (sorry, it just feels dirty to me) CD, and everything works. But it’s not quite right. It’s not perfect, and I don’t have portage, and I can’t use my shiny new computer to compile things all the time! (that was part of the reason I wanted such power ).

So I’m left with a dilemma. And because of my tendency to get paralyzed by indecision, I’ll probably stick with Vista for a while, until I figure out my solution, which will still probably involve dual-booting, since Wine doesn’t seem to be up to the task. If anyone’s got a similar situation/setup/solution, I’d love to hear about it. I love my Linux, but I also love my games.

1. mplayer’s tab-completion support does in fact come from bashcomp
2. this support is covered in the “base” module
3. the appropriate file uses strange regular expressions

At the time this bug was filed, the appropriate file to edit was (or was in) /etc/bash_completion. Since bash-completion-20081218, the bug was fixed, but the package also underwent some changes that seemingly caused locations of config files to change. (Apologies if this is incorrect, but I never went diving into the configs of bashcomp before now!)

In any case, the bashcomp configuration files are now in /usr/share/bash-completion. Since mplayer’s support is in base, the file that handles mplayer is “base” in that directory.

Now as for the “strange” regular expressions, that deserves some qualification. I’ve already seen lots of regular expressions on my (albeit rather short) day, but the reason I consider these ones strange is because they seem both unnecessary and redundant. The line in question is currently 5983 on my version 20081219-r1:

_filedir '@(mp?(e)g|MP?(E)G|wm[av]|WM[AV]|avi|AVI|asf|ASF|...|fl[iv]|FL[IV]...'

The two ellipses are my own adding, since the actual expression is one humongous line that ends up looking rather horrible here. My problems with this are both the explicit writing out of upper and lower case alternatives and the the bothering to do things like fl[iv]. Actually, I don’t have a problem with the latter except in the presence of the former. And to be fair, I probably wouldn’t have ever cared or noticed if I hadn’t been able to find “flv” when grepping numerous files. Not that “greppability” is necessarily a goal for configuration files, but it’s certainly annoying when it’s specifically hindered by regular expressions that save negligible space like the ones in this file.

As a final note, I’m going to disclaim that I’m no expert on bash scripting and the various intricacies of handling regular expressions therein, so I’d be happy to hear from anyone who knows better about why I should lay off the poor bash-completion folks.

External Links

• Gentoo Bugzilla bug on mplayer tab-completion
• Previous post on mplayer’s tab-completion

I’m not quite sure how the tab-completion infrastructure works, but I know it’s got a lot of “packages” for different programs. A surprising amount, actually. For the uninitiated, on my system, I’m looking at:

dfego@antica ~ $ eselect bashcomp list
Available completions:
[1] _subversion
[2] apache2ctl
[3] base *
[4] bitkeeper
[5] bittorrent
[6] cksfv
[7] clisp
[8] dsniff
[9] eselect *
[10] freeciv
[11] gcl
[12] gentoo *
[13] git *
[14] gkrellm
[15] gnatmake
[16] gpg2
[17] gvim
[18] harbour
[19] isql
[20] larch
[21] lilypond
[22] lisp
[23] mailman
[24] mcrypt
[25] mercurial *
[26] modules
[27] monodevelop
[28] mpc *
[29] mtx
[30] p4
[31] povray
[32] qdbus
[33] ri
[34] sbcl
[35] sitecopy
[36] snownews
[37] ssh *
[38] subversion *
[39] tig *
[40] tree *
[41] unace
[42] unrar *
[43] vim *
[44] xxd

The ones with the asterisks are ones I currently have enabled for my main user. As you can see, there are a lot of options to choose from, and for some weird reason, my git functionality died after a recent update. But wait… mplayer isn’t there… Interesting…

Interesting…

So where does mplayer’s tab-completion come from? It’s not just the normal one provided by the shell, because it before excluded certain file types.

Interesting. This must be investigated.

Cannot create link /etc/mtab
perhaps there is a stale lockfile?

Naturally thinking it was my project’s fault (it was), I rebooted into my normal kernel. To my horror, the same error came up. After a period of mini-panic, I ran to Google and at the same time reached for my Gentoo CD (the newest I could find was 2007.0 minimal, but it still works!). I ran e2fsck on both my home and root partitions for good measure, and then mounted my root partition and looked at /etc/mtab*. Apparently, the fact that there was mtab, mtab~, mtab~2205 and mtab~2213 isn’t normal. On recommendation from this obscure post from three years ago, I deleted the extra files (after examining them and noting they were not only extraneous but empty), rebooted, and viola! Problem solved!

Turns out a number of different things I did caused this error several different times. Not exactly sure why, but it always seems to coincide with the boot of or boot after a kernel oops or panic.

External Links

• Obscure post from 2006

Commonalities and Usage

First things first, equery and q are both very similar both in offered functionality and usage from the command line. Basic usage goes like so:

$ equery [command] [package]
or
$ q [command] [package]

Simple, right? There are also options to modify usage, but this is the most basic and common usage pattern.

In terms of functionality, equery and q have the following in common:

The usage of each of the above commands is pretty straightforward, so I won’t bore you with details. Running just “equery” or “q” from the command line will show all basic usage, and running one of the above commands without arguments (or with a -h local argument, for equery) will show similar usage info for the specific command.

equery

equery is a part of the gentoolkit package, is written in Python, and is rather well-endowed (in terms of features, of course). In terms of features unique from q, equery boasts:

• depgraph: display a dependency tree for a given package
• uses: display USE flags for a given package
• which: print full path to ebuild for a given package

Personally, of these three, I’ve only ever used uses, since I the few times I’ve ever attempted to use depgraph, the results have been too big to really get a handle on. Either way, the uses command makes it a lot easier to find out what USE flags are available for a particular package as well as their current states. Of course, you could just do a (not so quick):

$ emerge -pv [package]

However, that won’t give the information on what the USE flags actually are, just what their status is on the package.

equery in general gives more detail and nicer output than its shorter-named counterpart. Since I always like to see screen shots (yes, even from command-line programs), I’ll take the liberty of doing just that to illustrate my point:

Output of equery list zsnes command.

Output of qsearch zsnes command.

One thing to note about this particular command is that while qsearch automatically searches both installed packages and those in the portage tree, equery requires the -p option, as shown above, to do the same thing. On the flip side, qsearch has no capability (at this time) of searching overlays, but equery can be made to do so with the -o option. Tradeoffs, tradeoffs!

As a final note on equery, there are in fact two ways to call each of the sub-programs (like list, depgraph, etc.). There’s a short and long option for each of them, which is rather convenient. “equery l” is much nicer than “equery list” and “equery g” is way better than “equery depgraph.”

q

On to q! After reading the above section, you might wonder why anyone would want to use q when they’ve got equery in their toolbox. Is it for those few features that q has that are so dazzling? Is it because the name is shorter? No, no, let me just show you, you’ll understand:

Timed output of equery list zsnes.

Timed output of qsearch zsnes.

For those of you who can’t see the images or are just in plain shock, let me spell it out: q is fast. In that particular query, about 34 times faster. 34 times faster! That makes a big difference, whether you’re sitting in front of the keyboard twiddling your thumbs or putting it in a shell script. As a matter of fact, on running just the q or equery commands alone (to show the helpful usage messages), the speed difference is over 500 times! That being said, if you don’t need the fancy formatting and extra frills of equery for a given task, just use q. It’s faster. According to its Gentoo page, that’s its purpose anyway:

portage-utils is a collection of very fast utilities written in C, which are meant to offer a faster but more limited alternative to their gentoolkit counterparts. Please note that portage-utils is not meant to replace gentoolkit. Its utilities are much more efficient than the equivalent ones from gentoolkit and might be better suited to be used in scripts that need to call Portage repeatedly, but portage-utils does not offer the same functionalities.

Well hot-damn, I could have told you that from the beginning, no? It’s times like this that I sing the praises of C and mock all those Python people. Then I try to write a difficult program and cry myself to sleep.

Anyway, language wars and tearful nights aside, there are also a couple of other distinguishing things about q. First, its simple format can make parsing a bit simpler. Then again, it could make it harder, so let’s not go there. As a matter of fact, equery makes a point of modifying its output if you redirect its output. If you don’t like the modified style of output, you can pass the -N (–no-pipe) flag to turn that behavior off.

Second, q does bring a few unique functions to the table. Namely:

• atom: split up an atom string (like games-emulation/zsnes-1.51-r2 -> games-emulation zsnes 1.51 r2)
• cache: search the metadata cache
• grep: grep in ebuilds
• lop: emerge log analyzer
• merge, pkg, tbz2, xpak: all pertain to actually handling various types of packages, which I have no experience with, so I don’t know their usage.

The one that I find particularly is “lop.” In an example from that Gentoo page on portage-utils, try something like:

$ qlop -tH openoffice

It’ll tell you “the merge time” for that package. Now, I’m not sure if that means the last merge or some sort of aggregate. My output tells me:

openoffice: 9 hours, 19 minutes, 11 seconds for 12 merges

I’m guessing that means that it took 9:19:11 to merge 12 packages, in terms of the package in question and its dependencies, but I’m not totally sure on that one. Either way, this is a damn nifty feature. I make jokes all the time about how long some packages take to emerge, and how I can have actual times to back me up! Oh the joys of Gentoo…

As another very useful note, the qsearch command is also substantially faster than “emerge –search.” It’s not nearly as impressive as it is against equery, but it holds its own. An advantage that qsearch has over its equery counterpart, however, is that it has the ability (and has it default) of displaying descriptions of packages. I actually for a long time forgot how to do that on my system, and always ran to gentoo-portage.com.

Last but not least, just like equery, q commands can be shortened as well. Unfortunately, that just means changing something like “q search” to “qsearch.” Not a big improvement, but with a one-letter command, how much can you really ask for?

Why both?

In brief, the snippet above from the Gentoo article on portage-utils gives the answer quite nicely. q may be lacking, but it can be an order of magnitude faster than equery. For those times when you don’t need all that fancy-shmancy formatting and just want to get quick and dirty results, q is your tool.

The true problem arose when I attempted to actually implement changing my background. With fluxbox, this should be possible with a simple command like so:

fbsetbg -a -r /home/dfego/.fluxbox/backgrounds/

Simple enough, right? Well, as simple as it was, it just didn’t quite work. So I changed my cron timings, in case I got that wrong then used absolute paths, once again, just in case. Freaked out for a while, because the command itself works just fine. I ran it from a terminal about 29,834 times to make sure, but still, that little cron daemon that could just wouldn’t budge. It would, however, write the text “working” into ~/cronf*cker every minute. As a matter of fact, it still is. Allow me to go take care of that…

Now that that’s taken care of, I’ll go ahead and tell you what the real problem was. Apparently the cron daemon doesn’t have any inherent knowledge of the X display server I want to set the background of. Fair enough, since it starts running well before X gets started. But I didn’t realize this would matter, or even think about it at all until I saw a post online about setting fluxbox backgrounds in a more general sense. It proposed butting DISPLAY=:0.0 before the line, like so:

DISPLAY=:0.0 fbsetbg -a -r /home/dfego/.fluxbox/backgrounds/

I changed the file, bit my lip, and a second or so after the next minute passed, my background was changed anew! As a note, my X server is not using display :0.0, but rather :1.0. You can find out what your value is by opening up a terminal and typing:

echo $DISPLAY

Anyway, there you have it. My first pearl of wisdom to the world! Apologies for verbosity, but sometimes in explanations such as this, it helps. So the moral of the story/digest version: be aware of context when running commands for X! Or something like that. I actually was at work today trying to impress a co-worker of mine with the power of the command line, but unfortunately my attempt fell flat on its face when passing commands to xmessage. I’m not too worried about it though. My ping/grep antics seemed to be enough to win him over.

With that, I’m off to bed, and to watch my background change once more before daybreak!