Archive for scripts

ipod odyssey

Update: The info on SoundJuicer’s gstreamer settings is incomplete and will result in low kb/s rates and bad tags. Please see the next post for better information.

Wow.

Just…wow. I got an iPod recently and today I set out to start populating it with music using Linux. Not Mac, not Windows, but Linux.

To look at the copy, it’s pretty straight forward. For example, see here and here, which all cheerily say that, with a little bit of fiddling, it’s a breeze to set up one’s iPod with Linux.

Read the rest of this entry »

del.icio.us:ipod odyssey  digg:ipod odyssey

Comments (1)

expecting expect

Expect’s a wonderful scripting language. Oh, it has its oddities, but I’ve been using it for over ten years now, and it’s proven useful in a variety of ways.

What is it? It’s a Unix based, fully featured scripting language based on Tcl that can take control of a user’s input and output and make decisions about what to do based on the results it gets. In other words, it’s designed to run programs that are meant to be run interactively by humans and put them under automated control.

Its uses aren’t unlimited: it’s definitely a command based scripting method — you’re not going to be controlling GUI windows with this. In checking around, there’s actually a few windows ports, but none of them really control windowed applications (one of them merely runs off cygwin!)

Where it shines is in automating tasks (especially of the system administration kind), and in testing (provided of course that no GUI is involved). I used dejagnu for years when I used to test network devices (routers, bridges, printservers, webcams, etc.

I can put together a script that checks for a new version of software, ftps it over, unpacks it, compiles it and then notifies me. I can then switch the current symlink to the latest version (or not) as I choose — all the grunt work is already done. I can do the same with any kind of repetitive task on unix.

I currently use it to automate the process of updating our services at work. Basically we offer a searchable database of texts, and we periodically upload new texts. The process involves quite a bit of “preprocess” — we go through the texts beforehand, find the words, and build several databases based on those words to help speed up the inquiries. We have searches based both on straight text search (slow, but can find substrings, etc) or a much faster word based search. The latter is accomplished through preprocessing. So first, we take the texts, and extract all the words. From this we can create indices based on unique instances of the words (678 occurrences of the word DOG in the database), or Btrees containing the complete location (filename and byte location) of every individual word. There are also databases recording the citations, others that help us create outlines for the material. You get the idea: lots of individual texts, many separate little programs to extract useful information, and all of it eventually welded together into a format usable by our website. Some of these tools are written in C. Others in perl, etc. We invoke the database command line to load things up. Files get copied over. Things get checked out, updated, committed from CVS.

Expect comes to the rescue here. It checks that we have the new set of texts, starts up each of the utility scripts in the correct order (checks that each completed without problems before advancing to the next). It also gives the user a number of options on how to do this: where the text files are located, whether we are on production or development machines, we can run parts of it (the prepatory work, versus actual loading of the data once preprocess complete). It handles safety stuff, such as dumping database schemas and cvs’ing them before dropping databases and resconstructing them or copying/tarballing files off before replacing them. All of the tools are under CVS control, and the script knows enough to check for any updates and recompile as needed before using the tools. If you completely forget to set the tools up, it knows how to cvs check out the entire thing from scratch. Depending on which machine we run this on, it can take up to 24 hours to complete.

I can start it up and walk away from it. It’s wonderful. My coworker still gets to do his stuff by hand cos he hasn’t taken the trouble to put together a script for his stuff…

Some useful links for more info:
http://en.wikipedia.org/wiki/Expect
http://expect.nist.gov/
Also, dejagnu: http://www.gnu.org/software/dejagnu/

del.icio.us:expecting expect  digg:expecting expect

Comments

flickr slideshows

One of the problems with the SCLRR’s main page is that “slideshow” on it. It’s really an animated gif. Now there’s tons of (mostly Windows based) software out there for creating gif type slideshows as any google search will show you. But remember that I try to make this site pretty easily usable by the average volunteer. So for example that Dog of the Month you see is pulled out of the database with a bio that’s all done in the volunteer only section of the website. They don’t have to do anything more than check off the dog they want displayed and voila!

So I wanted something similar for the slideshow. I also wanted some way of uploading the pictures pretty easily. So I got the bright idea of using flickr. They’ve got an API. So the idea went something like this: I create a perl script that uses flickr’s API to pull out a list of pictures with a certain tag and then I rotate through those pictures in the file. So from the volunteer’s point of view. all they have to do is manage a set of pictures on flickr — which has a nice easy to use interface, and to which access can be given without compromising the shell account. Hey I love these people dearly, but I cringe at the thought of a non-technical person stomping all over the files in the account by accident. (I mean I have everything regularly backed up but still.)

del.icio.us:flickr slideshows  digg:flickr slideshows

Comments (1)

Bad Behavior has blocked 449 access attempts in the last 7 days.