The DF Lab

So after a big of Googling and finding this bug (after several others), I was made aware of three things (in response to my previous post):

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

linux gentoo, linux

After a long time of playing .flv files in mplayer on the command line in Gentoo, I noticed recently that they now tab-complete. I’m not quite sure how recently this change occurred or what caused it, but I’m very pleased with the update.

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.

linux gentoo, linux