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

As it turns out, after the first 8 characters, I could have put in anything at all, and the login would work. I was shocked that such a strange security issue would come up on a mostly stock-configured Ubuntu 8.04 server. In fact, it was better than stock configured, as I already had to do a bunch of configurations to secure it.

As it turns out, the problem lied with the way PAM was authenticating (or something). I went and checked that my configurations were right (you should have “md5″ in a “password” line where commented to do so in /etc/pam.d/common-password). Then, after doing some more poking around online, I found an Ubuntu forum post that mentioned that in /etc/shadow, if any given password has $1$ at the beginning, it’s using MD5. Upon looking at my shadow file, it turned out that one of my users (the one with the issue) was somehow not using MD5. I don’t quite know how that happened, but I’m going to guess that I configured PAM for MD5 after last setting his password. At least that’s my best guess.

To fix the issue, I just used passwd to change the password for the given user, and it properly took on its MD5 encryption. I hope this proves useful to someone in the future!

It’s actually rather ingenious if you think about it, and there are plenty of references that give great explanations of how it all works, so I won’t do that here. The short version is that the list actually acts like an element within another data structure, which allows it to work for all types, rather than having to create new structures and functions for every structure to act like a list. What I recently found myself trying to do was create a queue (first-in-first-out) data structure using the linked lists provided. I decided to go about this after getting a little advice from a couple of fellas over at Stack Overflow. I haven’t fleshed it all out yet, but came to an important realization on how things work. It’s not really all that hard, but it was important enough for me to want to document: because it is a circular, doubly-linked structure, adding an item to the front and back of the list look very similar. In fact, they’re pretty much the same operation, except for where the external head and tail pointers point to. They’re so similar that I spent a bunch of time confused on how it all worked. I suppose that’s my fault for delving in and examining the overly-short elegant code.

The result of this is that their list_add_tail() function (which is commented to be useful for queues) is, in fact, useful for queues. It adds an element linked after the “last” element and before the “first,” given the head of the list. “Last” and “first” are in quotes here because it’s a circular list, so there technically aren’t a first and last, but there are. Anyway, what I still don’t quite understand is how the list_add() function is useful for stacks (also in the comments). Though I’m getting myself slightly confused just thinking about it further, so I’ll end the tirade here.

I guess if there’s one thing I can pass on here, it’s that if there’s comments documenting a series of functions (which the kernel’s include/linux/list.h file does), listen to the comments. I suppose this was a learning experience for me in the end, but I could have saved a bunch of time by just trusting what they said the functions do. On the flip side, if you’re curious, don’t trust them, and want to be sure about what the code is doing, you are always free to dive right in! I’m just convinced that the kernel developers are a lot smarter than I am, at least at this point in my career.

Related Links

• Linux Kernel Linked List Explained
• Another Kernel Linked List Explanation
• Stack Overflow question about kernel queues
• list.h on Linux Cross Reference

• All my music (even the music I don’t listen to, so I don’t have to get rid of it)
• The music I listen to on my computer
• The music I have on my limited-space iPod

In addition, I wanted to make sure there was as little wasted disk space as possible, so I used hard links and had all the files in separate directories.

You’d think there would be a relatively simple solution, and I’d hope so too, but I came up with this really convoluted system that involved synchronizing three directories with two scripts whenever music had to be added or removed. What it results in is that I never add music anymore. And somewhere along the line, my “music on my computer” folder got messed up, so I’m back to square-one with that one. Hundreds of songs I filtered out back in the mix.

I wonder if some of my problems would be solved if I used a GUI music player, but I’m not so sure. My current setup uses MPD, which runs nice and light. Anyway, I’m out of mental energy, and am hoping someone else might have a better idea. Does anyone have any good ideas how to maintain my music? Or perhaps a better ideal to work under? Until then, I’ll just suffer under a horrible manual version where I just delete and add things at will to everything and hope I don’t miss things.