Category Archives: command a day

Command Line Case Study: Getting There, Getting Around (and some more often-unspoken basics)

FacebookTwitterShare

If you’ve ever wanted to get behind the graphical user interface (the GUI, pronounced “gooey”) of your computer and see a little more of what’s going on, you should explore the command line. What is the command line? If you’re like me, your first exposure was probably the black terminal screen and garish green pixelated text of MS-DOS, a blinking cursor flickering after the A> (it took my family a while to get a Tandy with a harddrive!) or the C:> prompt. In this series, though, I’m exploring some root functionality in a Unix environment.

Basically, the command line–or the command line interface (CLI)–is an interface through which you can, using a variety of text-based commands, do what programs on your Windows, Mac OS, Ubuntu (and so on) interface allow you to do visually. You can move files around, unzip archives, un/install programs, make programs, run programs, download, upload, and so on–providing you’re in the right place, have any necessary Internet connection, enjoy the right user privileges, and have the right tools at your disposal. In an earlier command line case study, I discussed my adventures with cp; this is one of the commands you would be running if you were using CTRL-C and CTRL-P to copy files between two folders. Anything you could do with a mouse click or by dragging and dropping, you can do from the command line–if you know how!

Most of us are using GUIs to interact with our computers, so I’ll assume that’s the case here. To access your local command line, you want to find the “terminal” program and run it. Different operating systems will put this in different places; sometimes hotkeys are pre-associated with it (CTRL-ALT-T sometimes works), sometimes it is already docked in your main menu, sometimes you have to hunt it down in your file structure. You can add a hotkey, if one doesn’t already exist.

Terminal will open to your own local machine–you’ll have to use a protocol like ssh (secure shell) to get into your server, and we’ll go over that, too. When I open terminal onto my local machine, I see the following prompt–though yours will look different!

tonya@sam:~$

The prompt above is my default–you’ll see my username, and then where I am–on the computer called Sam. This is the local hostname. If you change any of this information in your settings, it will change here. You can also change things manually; I won’t go into this, becuase it’s not really necessary at this point, and there are lots of good tutorials online (just google change terminal prompt ubuntu–or some similar set of terms). Before we get started, though, I want to introduce you to the man.

man

This is an indispensable command in terminal, especially for beginners–it stands for “manual,” and using it in combination with known commands (you can google many good lists of unix commands, but you do have to know what the command is before you look it up) gives you an account of the command, the different flags or qualifiers you can use with it to achieve specific results, and so on. For instance, man ls will give me the manual page of the command we’ll explore below, ls.

Most manpages are longer than one screen can display. So, to advance page-by-page, press the space bar. If you’ve read enough and want to escape the man, you can escape by quitting it–just type q. This is usually the way you escape, so when in doubt, hit q (or ESC).

You should be noticing by now that unix commands are essentially radical truncations of pretty-much everyday language. Now–let’s explore our surroundings!

ls

In terminal, type ls. This will list the current directory contents, at a very basic level–you’ll see a table of all the visible subdirectories and files, typically color-coded according to type. However, there are lots of ways you can see more fully into your directory contents using ls! You can read all about the full functionality of the ls command in its man page, but here are a few more specific commands that I like.

ls -a

You might have noticed with the first ls you ran that the list of files and subdirectories seemed rather brief and uninformative. That’s true–basic ls only gives you that information. If you want to see everything in the current directory, including hidden and system files, you need to lIsT -aLL, using the flag -a. Of course, you may not be able to read everything here, and it still won’t give you all the information you might want–like who owns the folder, what kind of permissions are associated with it, when it was created or updated, and so on. To see everything everything, use a command like this:

ls -a -l |less

What’s going on here? We’ve got a handle on the command and the first flag. The second flag, -l, will allow you to view the lONG version of the output. Okay–makes sense. What about the vertical line and the less? The vertical line is called a pipe, and it does what pipes do–pipe one thing into another. Here, we want to pipe the output of the too-long directory listing through another command, called less. You can read more about less, as you can with all commands, in its man page. Neat, huh? The pipe is a powerful tool, but I don’t know too much about it–maybe I’ll learn more and write a post about it sometime in the future….

cd

How do you move around in these directories and subdirectories? With the command cd, or cHANGE dIRECTORY. You can cd to any existing directories in your file system. Once you’ve changed your directory, notice that your prompt may change, at least on your local machine. On a server, that may not happen, and so you’ll need the command pwd to pRINT THE wORKING dIRECTORY. More about that later. Here are some ways to use cd:

cd Pictures
cd ..
cd Pictures/2012/2/
cd ../../2011/11

In order, what I’ve done above is cd to the subdirectory Pictures; then back to my original location with the .., which signifies back one level in the directory structure. Then, I dug two subdirectories down into Pictures; then, I backed two levels out and moved into the subdirectory 11 inside 2011.

mkdir & rmdir

What if you want to make a new directory? Use mkdir misc to–you guessed it–mAKE A NEW dirECTORY CALLED misc. You can probably use the forward-slash and the .. to make new nested directories, too. Let’s try!

mkdir Pictures/test
cd Pictures
ls

Yes, it works! Now, let’s delete that empty test directory so we can reuse the name.

rmdir test // reMOVES THE EMPTY dirECTORY test
cd Birds // cd to another directory parallel to Pictures
mkdir ../Pictures/test // makes a new directory called test one level back and inside the directory Pictures

Pretty cool, huh? Now, let’s see what your server looks like.

ssh

To get into your server, you’ll need to use a command like ssh–or sECURE shELL–to tunnel to the server via an existing and open Internet connection. I have a server at cerosia.org that I can access with my username, howe and my secret password, which I’m not going to share with you. Here's how I get there:

ssh howe@cerosia.org

I will be prompted to input howe@cerosia.org's password, which I do, and I’m in–after some information about where my server is, what system it’s running, last login time, date, location of last login, and so on. Once you’ve successfully shelled into your server, you’ll notice that the prompt looks a little different.

howe@li301-8:~$

The basic structure is the same, which can be confusing for some new users; my username, and then where I am–at a host named li301-8. This is why you might want to change the look of your remote prompt!

Now you’re here, you can pretty much use man,ls,cd, mkdir, rmdir, and other commands in the same way.

I hope this lengthy narrative gave you a good sense of how to move around in your directory structures, whether local or remote, in addition to answering some more fundamental questions that tech-oriented tutorials assume you already know. Next up: creating, viewing, editing, and saving files on your server. Or maybe, changing your prompts!

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.

Linux command a day?

Having had this netbook running ubuntu natty for a while, and having experienced the pains of not knowing how to do x, y, or z without fumbling about blindly in a maze alternating command line with google searches for “how to…” or “linux command reference kill,” I am contemplating starting a command-a-day series. My goal would be to learn–not merely to be able to do after having looked up–a good selection of the most important active commands, especially for dealing with wonky programs running on the local machine and for manipulating files/directories both on the server and on the local host, and downloading/installing/running programs from the command line. Also searching: grep confuses the heck out of me! At any rate, I could use your help. What, to your mind, are the most important (and useful, for a beginner) commands to learn? What about the most useful delimiters or modifiers? What should a beginner not mess with until a basic sense of the command structures has been grasped?