Introducing a Command Line Case Study: CP

I’ve been hanging out with Unix people for most of my life, and their interest in it has rubbed off–not, sadly, their expertise, but I’ve learned a bit here and there. I know enough to follow along in the conversation, mostly;  enough to see the value in the simplicity and straightforwardness of the command line; enough to get the appeal of text-based computing; and definitely enough to endanger my data.  On my own, I can usually make my way around, do what I need to do, and learn a few interesting tidbits (that quickly melt away from disuse, needing to be relearned seven months later) in the process, but without a little help from friends, things take forever. Admittedly, this is mostly because I don’t use the shell on a daily basis; I’m a dabbler, a dilettante. I’m the kind of person who will never willingly purchase a car with an automatic transmission, but I don’t really know how to change my own oil in an environmentally sound manner.

Recently, my sad lack of real skill with server structure and the basic commands needed to do stuff there, however, I have found vastly frustrating. At the 2012 THATCamp CHNM workshop on Omeka plugins, led with great aplomb by Patrick Murray-John, I was under the gun of time, my nemesis, and realized how little I actually knew. Not how much I could figure my way around, but how much I knew. Before I could follow the leader, I had to update my Omeka installation from 1.2 to 1.5 (see what I mean about the proverbial seven months later?)–and this took a ridiculously long time, given that we only had a brief span to play with. I finally managed to update things, in a very ham-fisted and inelegant sort of way, but by that time, the workshop was over.

This led me to consider a command-a-day series, which I’m hereby downgrading to a “commandline case study” series that will definitely not happen every day, but which will deal with particular problems or tasks a very introductory user–me, specifically–has encountered. Hopefully, it will happen on a semi-routine basis, at least. By narrating my process, and recording it for future me, I hope to build a clearer, cleaner, more controlled vocabulary of practice in unix that works for my learning habits. After all, I have a server on which I am running WordPress, Omeka, a few other doodads, and which I use as a general backup and trial space for everything else. I ought to know how to use it, at least a little. So, consider this my first entry!

When I went back to the Omeka plugins project, I realized that none of the files associated with the existing database were copied (I did a bang-up job of that update, right?). I needed to move everything from the first, un-updated install into the appropriate directory in the new install, so thumbnails &c would appear when browsing the Omeka site. In the directory structure, the subdirectories and files I need are in archive, located in ~/cerisia.cerosia.org/omeka/–and I needed to move everything into the appropriate subdirectory, ~/cerisia.cerosia.org/method/, where I’d updated the install.

Enter cp. In unix-speak, this is the ultra-condensed term for “copy.” Though why two additional letters couldn’t be used beats me. I thought I could use mv, or move, but that apparently only works on files, and I needed to move directories. And what’s more, I needed to move directories with directories within other directories, recursively. More on qualifiers or flags later, but for now, the thing to remember is -r, which tells the machine to do the command cp or whatever recursively.

The first time I tried this, I typed the following, from ~/cerisia.cerosia.org/omeka/:

cp -r archive ../method/archive

What’s going on here? Basically, I’m copying, recursively, a directory called “archive” that lives in ~/cerisia.cerosia.org/omeka/, to another directory one step back and in /method/archive. Can you guess what the problem is? Unfortunately, this created a subdirectory in the already-existing subdirectory archive! I’ll remove that later, when I learn rmdir.

I did it again:

cp -r archive ../method/

Success! Now, when I go back to my Omeka archive and refresh the page, all my object images and thumbnails are showing up. Yay! But, where is my header image, which I’d created myself and of which I was rather proud? That, too, needs to be moved. I found several images–apparently, I was testing different ones–in the default themes directory, but I’m not sure which is the current image in use. So, let’s just grab all of them!

As it turns out, you can also use cp to move multiple individual files into a specific directory. Again, the basic structure is the same, with the command, any flags, the file names separated by a space, and the destination directory. I used the following command to move three header images to the right location, so they would appear in my updated install:

cp bookwheel.jpg bookwheel_sm.jpg bookwheel_lg.jpg ~/cerisia.cerosia.org/method/themes/default/images/


All in all, this command is pretty useful–especially for beginners who are trying to install things, back things up, move things around, and rename files. To rename a file with cp, you use the full file name as the first argument, the target file name as the second argument, like this:

cp .htaccess old.htaccess

I did a lot of renaming with cp when updating the Omeka install, because I ended up installing the updated version not overtop of my existing install, but inside it. See what I mean about ham-fisted? You can use cp sort of remotely, too, as I did above in the first example–that is, if you get confused about moving whole directories and subdirectories, you might find it easier to stay at home and just spell out the whole directory structure, like this:

cp -r /home/cerisia.cerosia.org/omeka/omeka-1.5/ /home/cerisia.cerosia.org/method

Up next: getting around your server, the very basics. I kind of jumped the gun with cp–next time, I’ll take a step back and go over getting into your server with a tool like putty or from the terminal, and commands for looking around like pwd, cd, and ls.