Anyway, this all correlates to a recent issue I’ve had with my music accounting system, and how I got around it with some frenzied bash scripting. Because I’ve got a 4GB iPod Nano, I eventually came into the position of having too much music to fit on the device. So I looked at my music and thought about compression. Unfortunately, I couldn’t glean nearly enough space from that. Then I realized that I have way more music than I actually listen to, so why not keep some music for computer listening, and some for mobile? Well that’s a fantastic idea, but implementation gets a bit sticky. I can try some convoluted system in which I keep a file of the unwanted files, update that manually, and… yeah, not too pretty. Although I can’t quite say my solution was much prettier.

My current system involves a ~/music directory, and a ~/music-all directory. My intention is to delete nothing from ~/music-all, ever. ~/music contains music I actually want to listen to, and ~/music-ipod will contain music that I like enough to carry in my 4GB of space. The key is that all the files within these three directories are hard links, so I’m not actually increasing my disk usage very much, and operations on the sets of files are much faster than if I had more than one copy of my files. So assuming I hard link everything in ~/music-all to ~/music, I can then delete things from music at will, without losing it from my drive, but getting rid of it from listening.

With a schema in mind, then there’s the question of how to keep it up to date. There are times when I want to add music to my collection, but then what do I do? I could manually link the new files over, but… well, in retrospect, perhaps that would have been simpler. But I decided I needed a script which would note the differences, relink ~/music-all to ~/music, then remove the files that I noted earlier (which were saved in a text file). The benefit of all my toil was that it now makes my updates lightning fast and not tedious in the least. I had to come up with two scripts, however: one to be run prior to changes to ~/music-all, and one once they’re made. Below are the scripts, which probably won’t be of much use to anyone else, but they can essentially be used to keep two directories in sync, but with certain persistent changes.

mtree-1
mtree-2

Wow, I just spent way too much time figuring out how to post code here, and I’m still not satisfied with the result, so I ditched it. The built-in <code> tag doesn’t seem to take to multiple lines all that well… If anyone knows how to do that, do let me know!

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!